Wenn es um Flexibilität im Build-Management geht, distanziert man sich gern von Maven 2. Zwar kann man es durch diverse Einstellungen „umbiegen“, aber das ist nur teilweise zielführend. Möchte man wahrhaft flexibel sein und auch bleiben, so fällt die Entscheidung meist auf Gradle oder Ant. Gradle hat den Vorteil, dass man praktisch Java-Code schreiben kann, Ant zeichnet aus, dass es, so wie Maven 2, rein XML-basiert ist und dennoch als Script-Sprache klassifiziert wird. Apache Ivy erweitert die Funktionalität von Ant um alle notwendigen Features, die zum Auflösen von Abhängigkeiten nötig sind und ermöglicht die Publizierung von Artefakten in ein beliebiges Repository.
Verwaltung von Abhängigkeiten
Abhängigkeiten können aus verschiedenartigen Repositories geladen werden – es spielt keine Rolle, ob Maven 2 oder ibiblio, sogar Dateisysteme werden unterstützt. Für ein Projekt werden solche Abhängigkeiten in einer Ivy-Datei hinterlegt, die in der XML-Syntax formuliert werden. Zu einer solchen Abhängigkeit gehören normalerweise die Organisation und der Name (zumindest, wenn man gegen ein fremdes Repository geht, sollten diese Informationen vorhanden sein). Die Revision kann mit Wildcards angegeben werden. Das bietet Dynamik, denn man ist z.B. immer an der aktuellsten Wartung einer Bibliothek einer bestimmten Version interessiert. Dieser Punkt ist ein Vorteil gegenüber Maven 2, denn dort sind Versionen bzw. Revisionen immer statisch. Als Sahnehäubchen und sehr nützliches Feature kann man die Abhängigkeiten auf so genannte Konfigurationen abbilden. Das ermöglicht klare Differenzierung, z.B. für Kompilierung, Laufzeit und Tests. Sogar Vererbung gibt es zwischen solchen Konfigurationen. So ist es naheliegend, test von runtime erben zu lassen und nur um Test-Abhängigkeiten zu erweitern.
Verbesserte Versionierung gegenüber Ant
In Ant gibt es einen Task, welcher BuildNumber heißt. Ein sehr primitiver Task, der auf eine Datei zugreift, um dort die Build-Number zu lesen und zu schreiben. Der Wert geht von 1 bis n. Verglichen mit einer „echten“ Version ist das nichtssagend. Es ist sinnvoller, Versions- bzw. Revisionsattribute zu definieren – das ist die gängige Praxis. Mit Ivy kann man das auf die Spitze treiben und in eine beliebige Tiefe gehen. Das Task-Pendant in Ivy heißt ebenfalls BuildNumber (es wird in einem anderen XML-Namespace angesprochen), verwendet aber keine Datei zur Ermittlung der nächsten Revision, sondern greift auf ein Repository zu, um sich an der letzten existenten Revision zu orientieren. Ein Vorteil liegt hier auf der Hand: Wenn im weiteren Verlauf des Builds etwas fehlschlägt, dann wird nicht einfach eine Revision übergangen, sondern schlichtweg nicht erzeugt. Auch hier kann man, wie bei den Abhängigkeiten, nach Belieben auf Revisionsebenen zugreifen, um die Folgerevision der nächsten Ebene zu erhalten.
Der eine oder andere möchte an dieser Stelle vielleicht anmerken, dass der Task in Ant von PropertyFile erbt und deswegen weit mächtiger ist als hier dargestellt, doch ist es fraglich, ob man so weit ins Detail gehen möchte, um eine so selbstverständliche Funktionalität zu erhalten.
Ausgereifte Publizierung
Die im Punkt „Verwaltung von Abhängigkeiten“ bereits erwähnte Ivy-Datei ist als nichtveröffentlichte Version eigentlich nur rudimentär ausgeprägt. Sie dient nicht nur zur Deklaration von Konfigurationen und Abhängigkeiten, sondern enthält in veröffentlichter Variante auch Informationen wie z.B. den Status (standardmäßig integration, milestone oder release) und das Veröffentlichungsdatum. Es ist zwar möglich, eine vollständige Ivy-Datei zu verwenden und unberührt zu lassen, aber es nimmt eine gewisse Flexibilität. So ist es möglich, in dem publish-Task einen Status als Attribut mitzugeben und dadurch eine neue Revision als Snapshot zu erzeugen. Erst später, nachdem alle Tests abgeschlossen und Bedenken ausgeräumt wurden, wird sie als Release veröffentlicht.
Eclipse-Integration
Ein sehr hilfreiches Plug-in für Eclipse ist Apache IvyDE. Mit diesem können die in den Ivy-Dateien hinterlegten Abhängigkeiten für die IDE aufgelöst werden, und die statische Einbindung der benötigten Bibliotheken entfällt. Das spart Zeit und Änderungen sind zentral.
Nice to have/know
Mit dem makepom-Task kann man Ivy-Dateien in Maven 2-POM-Dateien konvertieren. Dies ermöglicht Kompatibilität zu entsprechenden Repositories, und so bewegt man sich in zwei Welten.
Alle Abhängigkeiten werden standardmäßig transitiv aufgelöst. Dieses Verhalten ist pro Abhängigkeit deaktivierbar.
Fazit
Der Titel verrät es vielleicht schon: Apache Ivy ist eine gelungene Software, die einem Entwickler immer wiederkehrende Arbeiten abnimmt und ihn dabei nicht unnötig einschränkt oder aufhält.
