Die Maven-Alternative?

Apache Buildr


Die Automatisierung der Build-Prozesse ist eine feine und wichtige Sache. In der Regel freut man sich, wenn ein Projekt Apache Maven verwendet und man dank der Konvention das Projekt sofort bauen kann. Doch mit der Zeit stellt sich in der Regel Ernüchterung ein: Der Build schlägt plötzlich fehl, weil ein Artefakt nicht mehr in den bekannten Repositories gefunden werden kann, die Ergebnisse sind nicht exakt reproduzierbar oder für eine kleine Erweiterung des Prozesses müssen erst aufwändig Plug-ins entwickelt und verteilt werden. Muss das so sein? Apache Buildr hat sich zu einer mächtigen Alternative entwickelt, indem es den deklarativen Ansatz von Maven mit dem imperativen einer Skriptsprache kombiniert.

Die Ursprünge von Buildr [1] liegen in der BPEL-Engine Apache ODE [2]. ODE ist ein komplexes Middleware-Projekt, das sehr hohe Anforderungen an das Build-System stellt. So besteht es aus über fünfunddreißig Modulen, unterstützt neun Datenbanken, wird in drei verschiedenen Editionen paketiert und hängt von über hundertzwanzig Bibliotheken ab. Die Datenbankanbindung erfolgt wahlweise über OpenJPA oder Hibernate – beide müssen im Build-Prozess berücksichtigt werden. Die Datenbankskripte sollen nicht nur für eine Datenbank, sondern gleichzeitig für alle neun erzeugt werden. Zusätzlich werden XML-Parser und -Serializer mittels XMLBeans generiert und eigene Annotations-Prozessoren für die Codegenerierung verwendet. Dazu kommen weitere „Kleinigkeiten“, wie die Anforderung, dass alle ausgelieferten Textdateien, auch die generierten, die Apache-Lizenz im Kopf führen müssen.

„Maven Uncertainty Principle“

Nach den guten Erfahrungen, die das ODE-Projektteam mit Maven 1 gemacht hatte, war man optimistisch, auch diese Anforderungen mit Maven – diesmal in Version 2 – umsetzen zu können. Das war auch tatsächlich möglich, allerdings mit deutlich höherem Aufwand als erwartet. Für eine so einfache Aufgabe wie das Zusammenführen von zwei SQL-Dateien benötigt man beispielsweise 34 Zeilen XML. Die SQL-Skripte für alle Datenbanken zu erzeugen, war mit Maven und Plug-ins gar nicht möglich, sodass man an dieser Stelle auf Ant-Skripte ausweichen musste. Im Ergebnis war die Build-Logik von Apache ODE um insgesamt 6739 Zeilen XML-Code gewachsen, verteilt auf 53 Dateien. Die Verteilung auf mehrere voneinander abhängige pom.xml-Dateien muss man in Kauf nehmen, wenn man sein Projekt auf mehrere Module verteilen möchte. Man kann sich vorstellen, dass das auf Kosten der Wartbarkeit geht...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang