Pascal Nutzen von so etwas wie Apache Maven kann frei?

Question

Apache Maven ist ein sehr beliebtes Build und Abhängigkeitsmanagement-Tool in der Java-Open-Source-Ökosphäre. Ich habe auf einige Tests herausfinden, ob es Free Pascal / Delphi Einheiten zusammengestellt verarbeiten kann und fand es einfach zu implementieren. So wäre es möglich, auf

• Release Open-Source-Bibliotheken vorkompilierte für Free Pascal (oder Delphi) in einer öffentlichen Maven-Repository
• enthalten Metadaten in diesem Repository, das Abhängigkeitsinformationen
enthält
• verwenden Maven auf der Kommandozeile die Open-Source-Bibliothek aus dem öffentlichen Repository zum Download, und lösen automatisch alle Abhängigkeiten
• lokale Repositories, als Stellvertreter arbeiten, verwendet werden könnten, häufig verwendete Binärdateien
zwischenzuspeichern
• automatische Prüfsumme Erzeugung und Prüfung (von Maven zur Verfügung gestellt) würde das Risiko des Herunterladens beschädigt Binärdateien reduzieren
• Quellcode und sogar Dokumentationsdateien können mit den Binärdateien zur Verfügung gestellt werden
• Binärdateien können mit oder ohne Debug-Informationen zur Verfügung gestellt werden
• Continuous Integration Server wie Hudson , CruiseControl- verwendet werden können Projekte, wenn Änderungen zu bauen wurde das Quellcodeverwaltungssystem und benachrichtigen Entwickler über Buildfehler
eingereicht

Diese Art des Dependency Management könnte für Open-Source-Projekten sehr vorteilhaft sein, die viele Drittanbieter-Bibliotheken mit komplexen Abhängigkeiten verwenden. Es würde durch die Verwendung falsche Versionen verursachten typische Konflikte vermeiden.

Für den Entwickler, der Workflow für die Bearbeitung und den Aufbau eines Projekts auf ein Minimum reduziert werden würde:

• Kasse das Projekt Quelle von internen Versionskontrollsystem
• bearbeiten Quelldatei (en)
• läuft mvn package, um automatisch alle erforderlichen Bibliotheken von Drittanbietern (vorkompilierte Einheiten) herunterladen, wenn sie noch nicht im lokalen Repository Workstation sind
• kompilieren und ausführen

Die einzige zusätzliche Datei für Apache Maven, die im Projektordner erforderlich ist, ist die pom.xml Datei, um die Projektinformationen enthält.

Edit: während Maven ist für einige der erforderlichen Aufgaben nutzbar, eine Lösung wie Maven in nativer Free Pascal Implementierung einige Vorteile hätte: keine Java SDK erforderlich, Unterstützung für alle Entwicklungsplattformen, wo Free Pascal verfügbar ist, Wartung und Plugin-Entwicklung in Pascal.

Die Nutzung eines Maven-ähnlichen Werkzeug würde für Open-Source-Projekte nicht nur hilfreich sein -. Kommerzielle Projekte könnten zugreifen und die Artefakte in den öffentlichen Maven-Repositories in der gleichen Art und Weise wie auch verwenden

Maven Features aufgelistet unter http://maven.apache.org/maven-features.html

---

Update:

ein Anwendungsfall könnte der Bau des Lazarus, wo Maven würden alle erforderlichen Bibliotheken herunterladen und die Compiler mit den notwendigen Build-Pfad Argumenten aufrufen. Änderungen der Abhängigkeiten von den unteren Ebenen würden automatisch bis zum übergeordneten Build vermehrt werden.

Mögliche Vorteile:

• weniger Zeit, eine neue Arbeit gründen erforderlich Station, keine manuelle Installation von Bibliotheken von Drittanbietern erforderlich
• weniger Fehler durch falsche Bibliothek verursacht Versionen, Erkennung von Version Konflikte (zum Beispiel, wenn zwei Bibliotheken sind abhängig von verschiedenen Versionen einer dritten Bibliothek)
• Artefakte, die inhouse erstellt werden kann auf den lokalen Maven hinzugefügt werden Repository und geteilt zwischen Entwickler und Projekt, zentral Speicherung aller Artefakte mit Metadaten
• baut reproduzierbar sind, nur durch unter Verwendung der gleichen Quelle und Projekt Metadatendatei (pom.xml)
• kann die Entwicklungszeit verkürzen und Erhöhung Projekt Stabilität

Update # 2: FPMake

FPMake System bauen für Free Pascal scheint ein Werkzeug mit viel Potential zu sein, ist es in vielen Details ganz ähnlich wie Maven ist:

• FPMake ist ein pascal-basiertes Build-System entwickelt für und verteilt mit FPC
• FPMake das Gebäude standardisiert durch einige Grenzen wie Standardverzeichnisse definieren
• der Befehl fppkg <packagename> in einer Datenbank für das Paket aussehen wird, extrahieren, und dann fpmake.pp kompilieren und ausführen
• hat Standard Build-Ziele (sauber, bauen, installieren, ...)
• kann es eine ‚offensichtliche‘ Datei für den Import in ein Repository (wie mvn deploy oder mvn install) erstellen, ist das Manifest eine XML-Datei, die zu einem pom.xml in Maven sehr ähnlich aussieht:

FPMake Manifest-Datei:

      <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>

Answer 1

hat in Freepascal ein Kreuz auf einem Paketsystem der eigenen arbeitet zwischen apt-get und Ports-Stil. (Download-Quelle / build / install automatisch), genannt fppkg. Allerdings Arbeit ist ins Stocken geraten. Menschen investieren Zeit sind der Engpass, nicht die Menschen Werkzeuge wählen wollen.

Was Maven geht, ich weiß nicht wie auxilary Tools, die Installation von großen externen Runtimes müssen. Es könnte für eine große große app (wie Open Office) in Ordnung sein, aber nicht für eine util.

Ich habe auch lieber ein Tool, das sich auf die FPC Realität und Workflow ausgelegt ist. Dokumentations-Tools, Build-Tools, download Systeme, Testsuite-Systeme sind bereits alle da, es muss nur eine Person, die viel Zeit in sie widmet, um sie geschehen.

Einige typischen Probleme, wenn eine neue Technologie in einem Projekt als FPC Einführung und warum hat es eine Tendenz, ihre eigenen Werkzeuge zu machen:

• müssen 20+ Committer in Teilzeit- trainieren.
• Der einzige gemeinsame Programmiersprache Sie davon ausgehen können, ist Free Pascal. Auch Innenleben Delphi kann nicht für (viele Committer kam direkt auf FPC oder sogar noch über TP oder ein Mac Pascal) bekannt vorausgesetzt werden
  • Offensichtlich das macht etwas mit Plugins in einer anderen Sprache ärgerlich.
• Bash-Skript ist eine enge Sekunde. (G) machen Drittel, aber schon eine Größenordnung weniger.
• Alle Server sind * nix-wie (FreeBSD, OS X, Linux), aber nicht alle laufen Apache. (Zum Beispiel mein FreeBSD-Spiegel läuft XSHTTPD)
• jemand sachkundigsten muss Maintainer für eine lange Zeit gewidmet werden. Probleme beheben, aktualisieren / zu tun Migrationen usw. perferably mehr als ein aus offensichtlichen Gründen.
• ein großen Schmerzen sind Linux-Distributionen (und FreeBSD in geringerem Maße), sind die meisten Maintainer von * nix-Paketen nicht mehr fähig als „./configure;make;make installieren“, und muss mit einer in der Nähe von bebaubaren Repository Spoonfed werden und auxilary Dateien.
  • In-Verteilung Verpacken von FPC / Lazarus ist schon immer wichtig gewesen, und nach wie vor steigt
  • Alle Distributionen haben ihre eigenen speziellen Regeln über Metadaten, depedancies und wie Quellen veröffentlicht werden müssen. Besonders sehr bürokratisch Debian / Ubuntu ist und langsam.
  • Die meisten mögen keine dritte Partei Auto-Installateure auf ihre Systeme (da, dass ihre dependancy Kontrolle umgeht)

Dies alles führt zu der effektiven Praxis, die Tools in Pascal mit minimalem scripting am besten funktionieren besitzen. Einige Geräte verwendet:

• gmake wird hauptsächlich verwendet, um den Build-Prozess auf einem pro Verzeichnisebene parametrisieren, einen Nachfolger, fpcmake (kein Make-Derivat trotz des Namens wirklich) begonnen hat, aber die Migration nicht abgeschlossen hat.
• Latex und ein Latex HTML-Konvertierung (tex4ht, aber Debian verwendet Hevea) sind in der Dokumentation Gebäude (die nicht Bibliotheks-Dokumentation)
verwendet
• Die Community-Site (Netscape Community-Server, die TCL Scripting verwendet, ein schwerer komplexer Anwendungsserver) hat ein Problem, seit es begann, aber besonders in letzter Zeit, da der Betreuer wurde weniger aktiv.
• Mantis war ein Problem (speziell die E-Mail-Modul würde den Server zum Absturz bringen oder lahm aufgrund des Volumens), aber es hat sich in Form während der aufeinander folgenden Updates und harte Arbeit von mehreren lazarus devels gepeitscht worden. Derzeit ist es ein ordentliches Arbeitstier.
• lazarus.freepascal.org PHPBB Forum OTOH ist relativ schmerzlos, da viele jüngere Menschen wissen, wie sie damit umgehen.
• Das gleiche gilt für Umstürze (obwohl die erweiterte Skala einige Einstellungs braucht, nicht jeder ist tief in die Ins und Outs der mergetracking)

Wenn jemand über Maven wirklich ernst ist, würde ich ihn in der Regel fragen:

• CRITICIALLY die Nutzung für das Projekt untersuchen. In ganz konkret, mit Zeitplan und Zeitschätzungen. Vogelaugenhöhe „alles möglich“ Übersichten sind essentialy wertlos.
• Geben Sie einige Gedanken über die künftige Veränderung der verwendeten Technologien. Jede Technik ist Ereignisually ersetzt, auch die im Haus sind sie sogar in 18 Jahre + Projekte. Eine neue Technologie darf nicht machen Migrationen von anderen Infrastrukturkomponenten hart oder beteiligt. Die neue Technologie alle neuen Technologien zu Ende ist nicht vorhanden.
• Erstellen Sie einen Migrationsplan. Migration ist oft unterschätzt und unterschätzt.
• Und am Ende gibt es immer die 1000000 Euro Frage, die die tägliche Wartung tun?

Beachten Sie, dass in einem Unternehmen Sie treten nur die Person, die für den Anwendungsserver. Aber in einer informellen Umgebung dies ist viel schwieriger, besonders langfristig, da das Leben der Menschen, Berufe und Zeit für das Projekt ausgegeben variieren.

Answer 2

Klingt wie ein interessanter Plan, aber die Delphi-Community (und FPC noch mehr, ich kann mir vorstellen!) Werte Bibliotheken als Quelle weit mehr als vorkompilierte Bibliotheken. Der allgemeine Konsens ist, dass jeder, der eine binary-only-Bibliothek verwendet, ist ein Narr, aus zwei Gründen:. Sie können keine Fehler beheben Sie es finden, und Compiler Änderungen Kompatibilität brechen