Pourrait gratuite Benefit Pascal de quelque chose comme Apache Maven?

StackOverflow https://stackoverflow.com/questions/1893469

Question

Apache Maven est une construction et un outil de gestion des dépendances dans l'écosphère open source Java très populaire. Je l'ai fait quelques tests pour savoir si elle peut gérer compilé Free Pascal / unités Delphi

De cette façon, la gestion de la dépendance pourrait être très bénéfique pour les projets open source qui utilisent de nombreuses bibliothèques de tiers avec des dépendances complexes. Il éviterait les conflits typiques causés par l'utilisation des versions erronées.

Pour le développeur, le flux de travail pour le montage et la construction d'un projet serait réduit au minimum:

  • Voir la source du projet de système de contrôle de version interne
  • fichier modifier source (s)
  • run mvn package pour télécharger automatiquement toutes les bibliothèques de tiers requis (unités précompilés) si elles ne sont pas encore dans le dépôt local du poste de travail
  • compiler et exécuter

Le seul fichier supplémentaire pour Apache Maven qui est nécessaire dans le dossier du projet est le fichier pom.xml contenant les informations du projet.

Edit: alors que Maven est utilisable pour certaines des tâches requises, la mise en œuvre d'une solution comme Maven dans Free Pascal natif aurait certains avantages: pas de Java SDK requis, le soutien à toutes les plates-formes de développement où Free Pascal est disponible, la maintenance et le développement plug-in en Pascal.

L'utilisation d'un outil comme Maven ne serait pas utile pour les projets open source uniquement -. Projets commerciaux pourraient accéder et utiliser les artefacts dans les dépôts de Maven publics de la même manière et

caractéristiques de Maven sont répertoriées à http://maven.apache.org/maven-features.html

Mise à jour:

un cas d'utilisation pourrait être la construction de Lazare, où Maven télécharger toutes les bibliothèques requises et invoquer le compilateur avec les arguments de chemin de construction nécessaires. Les changements dans les dépendances sur les niveaux inférieurs seraient automatiquement propagées jusqu'à la génération parent.

Les avantages possibles:

  • moins de temps nécessaire pour mettre en place un nouveau travail la station, aucune installation manuelle bibliothèques tiers requis
  • moins d'erreurs causées par une mauvaise bibliothèque versions, la détection de la version les conflits (par exemple, si deux bibliothèques dépendent différents versions d'une troisième bibliothèque)
  • artefacts qui sont créés inhouse peut être ajouté à la maven locale dépôt et partagé entre les développeurs et les projets, centrales le stockage de tous les artefacts avec métadonnées
  • construit sont reproductibles, juste en en utilisant la même source et projet fichier de métadonnées (pom.xml)
  • peut réduire le temps de développement et augmenter la stabilité du projet

Mise à jour # 2: FPMake

FPMake construire le système pour Free Pascal semble être un outil avec beaucoup de potentiel, dans de nombreux détails, il est tout à fait similaire à Maven:

  • FPMake est un système de construction à base de pascals élaborés et distribués avec CPF
  • FPMake standardise le bâtiment en définissant des limites comme des répertoires standard
  • la commande fppkg <packagename> regardera dans une base de données pour le paquet, extraire, puis compiler et exécuter fpmake.pp
  • il a des objectifs standards de construction (propre, construire, installer, ...)
  • il peut créer un fichier « manifeste » convenant à l'importation dans un dépôt (comme mvn deploy ou mvn install), le manifeste est un fichier XML qui ressemble beaucoup à un pom.xml Maven:

fichier manifeste FPMake: 

      <packages>
        <package name="my-package">
          <version major="0" minor="7" micro="6" build="1"/>
          <filename>my-package-0.7.6-1.zip</filename>
          <author>my name</author>
          <license>GPL</license>
          <homepageurl>http://www.freepascal.org/</homepageurl>
          <email>myname@freepascal.org</email>
          <description>this is the package description</description>
          <dependencies>
            <dependency>
              <package packagename="rtl"/>
            </dependency>
          </dependencies>
        </package>    
      </packages>

Pas de solution correcte

Autres conseils

Freepascal travaille sur un système de paquet propre dans un croisement entre le style apt-get et les ports de freebsd. (Télécharger la source / build / installer automatiquement), appelé fppkg. Cependant le travail est au point mort. Les gens à investir du temps sont le goulot d'étranglement, pas des gens qui veulent choisir des outils.

En ce qui Maven va, je n'aime pas les outils AUXILIAIRES qui ont besoin d'installation d'énormes runtimes externes. Il pourrait être très bien pour une grande application majeure (comme Open Office), mais pas pour un util.

Je préfère aussi un outil qui est conçu pour la réalité et CPF workflow. Les outils de documentation, construire des outils, des systèmes de téléchargement, les systèmes sont déjà testsuite tous là, il faut juste une personne qui consacre beaucoup de temps en elle pour y arriver.

Quelques problèmes typiques l'introduction d'une nouvelle technologie dans un projet CPF, et pourquoi il a tendance à faire ses propres outils:

  • besoin de former 20+ committers à temps partiel.
  • La seule langue de programmation commune, vous pouvez supposer est Free Pascal. Même Delphi fonctionnement interne ne peuvent pas être pris pour acquis à connaître (beaucoup committers sont venus directement à CPF ou même encore par TP ou un Mac Pascal)
    • Il est évident que cela fait quelque chose avec des plugins dans une autre langue ennuyeux.
  • script Bash est une seconde près. (G) faire troisième, mais déjà une ampleur moins.
  • Tous les serveurs sont * nix (FreeBSD, OS X, Linux), mais pas tous Apache exécuter. (Par exemple mon miroir FreeBSD fonctionne XSHTTPD)
  • quelqu'un doit être le plus knowledgable mainteneur dédié depuis longtemps. Correction de problèmes, mise à jour / faire des migrations, etc. perferably plus d'un pour des raisons évidentes.
  • une douleur importante sont les distributions Linux (et FreeBSD à un degré moindre), la plupart des forfaits mainteneurs * nix ne sont pas capables de plus que « ./configure;make;make installer », et doit être Spoonfed avec un dépôt près assemblable et les fichiers AUXILIAIRES.
    • Dans distribution emballage de FPC / Lazarus a toujours été important et ne cesse d'augmenter
    • Toutes les distributions ont leurs propres règles particulières sur les métadonnées, depedancies, et comment les sources doivent être publiées. En particulier, Debian / Ubuntu est très lent et bureaucratique.
    • La plupart n'aiment pas la troisième auto-installateurs parti au-dessus de leurs systèmes (depuis pontages leur contrôle de dépendance)

Tout cela conduit à la pratique efficace propres outils Pascal avec le travail de script minimal mieux. Certains outils utilisés:

  • GEffectuez est principalement utilisé pour paramétrer le processus de construction sur un niveau par répertoire, un successeur, fpcmake (pas vraiment un dérivé de marque malgré le nom) a commencé, mais la migration n'a pas terminé.
  • latex et un latex à la conversion HTML (tex4ht, mais debian utilise Hevea) sont utilisés dans le bâtiment de la documentation (la documentation non bibliothèque)
  • Le site communautaire (serveur communautaire netscape qui utilise des scripts TCL, un serveur d'applications complexe lourd) est un trouble depuis qu'il a commencé, mais surtout ces derniers temps depuis le mainteneur est devenu moins actif.
  • Mantis a été un problème (en particulier le module e-mail échouerait ou boiteux le serveur en raison du volume), mais il a été fouetté en forme lors de mises à jour successives et le travail acharné de plusieurs devels lazarus. À l'heure actuelle, il est un bourreau de travail décent.
  • lazarus.freepascal.org forum PHPBB OTOH est relativement indolore car beaucoup de jeunes gens savent comment y faire face.
  • va de même pour subversions (bien que l'échelle plus avancée a besoin d'un ajustement, pas tout le monde est profondément dans les tenants et les aboutissants de mergetracking)

Si quelqu'un était vraiment sérieux au sujet de Maven, je lui demande souvent:

  • CRITICIALLY étudier l'utilisation du projet. De façon très concrète, avec des estimations de calendrier et de temps. niveau des yeux aperçus oiseaux « possibles de tout » sont essentialy sans valeur.
  • Donner une réflexion sur l'évolution future des technologies utilisées. Chaque technologie est l'événementsivement remplacé, même ceux en interne, en 18 ans + projets. Une nouvelle technologie ne doit pas faire des migrations d'autres éléments d'infrastructure difficiles ou impliqués. La nouvelle technologie pour mettre fin à toutes les nouvelles technologies n'existe pas.
  • un plan de migration. La migration est souvent sous-estimés et sous-estimé.
  • Et à la fin, il y a toujours la question 1000000 Euro, qui fera l'entretien quotidien?

Gardez à l'esprit que dans une entreprise vous botter juste la personne responsable du serveur d'applications. Mais dans un environnement informel c'est beaucoup plus difficile, surtout à long terme, car la vie des gens, les occupations et le temps passé sur le projet varient.

Sons comme un plan intéressant, mais la communauté Delphi (et encore plus CPF, j'imagine!) Les valeurs des bibliothèques en tant que source beaucoup plus que les bibliothèques précompilés. Le consensus général est que toute personne qui utilise une bibliothèque binaire est seulement un fou, pour deux raisons:. Vous ne pouvez pas corriger les bugs que vous trouvez dans, et les changements de compilateur compatibilité casser

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top