Ameise/Efeu für die Projektentwicklung

Question

Ich erwäge, ein Maven-Projekt, das ich verwalte, auf Apache-Ant/Ivy umzustellen. Ich brauche mehr Kontrolle über den Build-Prozess und bin mit Maven sehr frustriert. Bitte keine Kommentare darüber, wie toll Maven ist. Meine Frage bezieht sich auf Ivy.

Ich möchte eine "Standard"-Ant-Build-Vorlage einrichten, die später für andere Projekte mit minimalen Änderungen verwendet werden kann.

Ich werde ein zentrales "Unternehmens"-Repository einrichten, in dem wir Bibliotheken von Drittanbietern ablegen können, die nicht in den öffentlichen Maven-Repositories verfügbar sind (z. B. kommerzielle Bibliotheken, Sun-Bibliotheken, proprietäre Bibliotheken usw.). Dieses Unternehmens-Repository wird in unserem lokalen LAN verfügbar sein, ist aber möglicherweise nicht von außerhalb des Büros zugänglich.

Jeder Entwickler hat ein privates Repository in ~/.ivy/repository . Ich möchte, dass der Ant-Build dieses private Repository automatisch mit geänderten Versionen von Bibliotheken aus dem Unternehmens-Repository aktualisiert.

En ~/.ivy/ant Ich plane, "Standard"-Module für die Einbeziehung in das individuelle Projekt zu platzieren build.xml Dateien, unter Verwendung der include Aufgabe in Ant 1.8. Diese Module bieten Dinge wie Scala y Clojure Kompilierungsziele mit verschiedenen Versionen für verschiedene Scala- und Clojure-Versionen (z.B.: scala-compile-2.9.1.xml , clojure-compile-1.3.xml Die Build-Module sind im Unternehmens-Repository verfügbar und sollten automatisch in den privaten Repositories aktualisiert werden, wenn sie sich ändern.

Jedes Projekt wird einer Standard-Maven-Verzeichnisstruktur folgen: ${project}/src/main/java , ${project}/target/classes etc.

In der Vergangenheit habe ich versucht, Ivy zu verwenden, aber die Ant-Build-Dateien wurden sehr groß (> 500 Zeilen für die Template-Build-Datei) und schwer zu verwalten/bearbeiten. Ich hoffe, dass ich durch die Aufnahme von Standardzielen in ihre eigenen Build-Module in der ~/.ivy/ant Verzeichnis, kann ich diese Codeaufblähung vermeiden.

Ist das machbar? Liege ich da völlig falsch? Die einzige Dokumentation, die ich über Ivy finden kann, ist auf der Apache-Website (http://ant.apache.org/ivy). Gibt es noch andere Dokumentationen, einschließlich Bücher?

Answer 1

Ziemlich vernünftige Idee, die Vorlagendatei in einbindbare Hilfsdateien aufzuteilen. Persönlich bin ich jetzt switchin 'ein wirklich großes Projekt von ant (keine Abhängigkeit Verwaltung überhaupt - nur Kopieren von Dateien aus ftp) zu ant/ivy-Lösung. Also habe ich es so gemacht - ich habe eine Datei mit Meilensteinzielen - d.h. fertig zum Kompilieren, kompiliert, bereit zum Archivieren, archiviert - und so weiter. Ich denke, Sie haben die Idee. Ich habe Abhängigkeiten von all diesen Zielen konfiguriert (Abhängigkeiten im Sinne von Ant, verstehen Sie mich nicht falsch). Auf diese Weise - kompiliert hängt von bereit-zu-kompilieren, bereit-zu-kompilieren hängt von initialisiert - smth wie diese. Diese Targets haben keinen Body - sie sind dazu da, um in jede Build-Datei jedes Moduls deines Multi-Modul-Projekts aufgenommen zu werden. Der einzige Zweck dieser Targets ist es, den STATE des Builds aufrechtzuerhalten, denn durch dieses Import-Zeug werden die Dinge ziemlich knifflig und es ist schwer zu wissen, welches Target überschrieben wurde und wann dieses Target ausgeführt werden würde. Aber mit dieser Datei kann ich einfach den Status von vy build auf jedem sinnvollen Meilenstein ändern. Ich möchte in einem Modul Hilfedateien mit einer externen Exe kompilieren. Kein Problem - in diesem Projekt mache ich das einfach - die Archivierungsbereitschaft hängt vom Ziel für die Kompilierung der Hilfe ab. Und da diese Meilensteine Ziele enthalten sind - ich kann nur einige von ihnen überschreiben - alle anderen würden die gewünschte Art und Weise der Gebäude Projekt vorgeben.

Ein weiterer Teil meiner Strategie - Mixins bauen Dateien - für jeden spezifischen Bereich. Ich habe also eine Datei für Efeu. Dort setze ich initialisieren, auflösen, veröffentlichen und so weiter. Wenn ich Ivy verwenden möchte, füge ich einfach diese Datei ein und verwalte die Abhängigkeiten über meine Meilensteinziele. Wenn der Build typisch ist - ich füge nur diese Datei ein und habe eine Konvention-über-Konfiguration-Funktionalität. Alles aus der Box heraus. Wie das? Durch die Kombination mit anderen Mixins. Mixins können andere Mixins einschließen, die von ihnen abhängen. So ist jedes Mixin ein wiederverwendbarer Teil meiner Build-Strategie. Das Zeug aus OOP - single-concerned unit. In Ihrem Fall ist es Scala Mixin mit Zielen speziell für Scala Zeug.

Dann habe ich delegate.xml, die Kind-Projekte gemeinsame Build-Aktivitäten delegiert. Ich habe dist, all, test und was auch immer Sie für Multimodul-Projekt wollen. Die Build-Reihenfolge wird mit ant-ivy Aufgabe buildlist ausgewertet.

Es gibt auch einige andere Dateien - aber dies sind die strategisch grundlegenden Dateien, die mir geholfen haben, ein wiederverwendbares und wartbares Build mit diesem großen und sehr konservativen Projekt zu haben. Also, wenn u über Details interessiert sind, seien Sie nicht schüchtern und kontaktieren Sie mich. Ich werde sehr froh sein, Ihnen zu helfen, weil ivy docs sind wirklich kompliziert und unvollständig.

EDIT: Über Bücher - Ameise in Aktion könnte dir helfen, ich habe einige Ideen aus diesem Buch genommen, und ich empfehle es wirklich jedem zu lesen. Dort kann man auch Ivy-Zeug finden. Und was die Ivy-Dokumente angeht - sorry, das ist alles, was verfügbar ist. Aber als ich Probleme mit diesem umständlichen ivy+ant hatte, fand ich einige interessante Artikel in privaten Blogs. Also ... das könnte die Lücke irgendwie füllen.