Maven

Der Best-of-Bread-Ansatz hat Vor- und Nachteile. Die eingesetzten Tools sind für ihren Zweck optimal, eine bessere Integration wäre aber oft wünschenswert. Auch dafür gibt es Software, die den Gedanken des Buildsystems aus der Erfahrung heraus weiterentwickelt.

Maven [7] ist ein solches System. Es stellt Konvention vor Konfiguration. Das bedeutet: Je enger sich Projekte in ihrer Struktur und den Entwicklungsschritten an das Maven-Modell halten, umso kleiner fällt das Buildfile aus, da Maven stark auf eingebaute Regeln und Verhaltensweisen aufbaut. Maven arbeitet also normativ, denn selbst das Verzeichnislayout der Quellen ist vorgegeben. Wer auf seinem individuellen Weg besteht, wird mit Maven nicht glücklich. Man kann zwar alles konfigurieren, aber der Aufwand wird immens.

Ein weiterer wichtiger Aspekt von Maven ist seine deklarative Natur. Statt eines Makefile definiert der Entwickler sein so genanntes POM, das Project Object Model. In dieser XML-Datei spezifiziert er, wie seine Komponenten aussehen und welche Projekt- und Bibliotheks-Abhängigkeiten es gibt. Die üblichen Buildziele und Buildregeln stehen nicht im Zentrum, zumindest in der Theorie.

Maven führt eine Reihe nützlicher Konzepte ein: Entwickler hinterlegen Bibliotheksabhängigkeiten im Buildfile und Maven lädt bei Bedarf während des Build aktuelle Bibliotheksversionen aus öffentlichen oder privaten Repositories herunter. Den Ablauf steuert der Anwender bei bedarf feingranular über Versionsattribute. Maven-Repositories könnten in die Rolle wachsen, die zum Beispiel das CPAN für Perl spielt.

Phasen

Ein zentrales Maven-Feature sind die Lifecycles, die wiederum aus einzelnen Phasen bestehen. Der Clean-Lifecycle etwa enthält die Phasen »pre-clean« , »clean« und »post-clean« , der Default-Lifecycle erstreckt sich entsprechend von »validate« über »compile« , »test« , »package« bis hin zu »deploy« .

Phasen wiederum sind verknüpft mit den so genannten Goals von Plugins, die dann die eigentliche Arbeit tun. Abhängig vom Package-Typ des Projekts sind verschiedene Default-Goals an die Phasen geknüpft. Für Jars ist das zum Beispiel das »jar« -Goal des Jar-Plugin. Konfigurationsaufwand steht hier wieder nur für Entwickler an, die etwas anderes wollen, als der Maven-Standard vorgibt.

Ein drittes wichtiges Feature von Maven sind die Buildprofile. Diese kapseln umgebungsspezifische Konfigurationen für ein Projekt, zum Beispiel Servernamen, Datenbankverbindungen, Benutzer und so weiter. Hier gibt es Unterschiede nicht nur für jede produktive Plattform, sondern auch innerhalb des Entwicklungsprozesses, je nachdem, ob gerade ein Deployment auf eine Test- oder Produktionsumgebung stattfindet.

All das sieht vom Konzept her gut durchdacht aus, hier sind Erfahrungen aus echten Projekten sowie aus der Vergangenheit eingeflossen. Maven gibt es seit Anfang Oktober in der Version 3.0. Wer auf der grünen Wiese mit einem Projekt anfängt, das eine gewisse Komplexitätsstufe erreichen wird, der sollte Maven auf alle Fälle in Betracht ziehen. Existierende Projekte nach Maven zu portieren, könnte dagegen wenig Vorteile bringen, abhängig davon, wie viele Spezialitäten sich über die Zeit angesammelt haben.