Die Maven-Alternative?

Apache Buildr

Tammo van Lessen


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. Zudem sind die Konfigurationsoptionen verschiedener Plug-ins nicht immer selbsterklärend und ändern sich mitunter zwischen Plug-in-Versionen. In der Praxis führt dies zu schwer aufzuspürenden Problemen und zu nicht reproduzierbaren Builds. Scherzhaft sprach man sogar vom „Maven Uncertainty Principle“, in Anlehnung an Heisenbergs Unschärferelation.

Notausgänge

Dass dies besser gehen muss, steht außer Frage – aber wo genau liegt eigentlich das Problem? Maven verfolgt einen rein deklarativen Ansatz mithilfe einer XML-basierten DSL. Diese DSL ist allerdings ausschließlich in der Lage, das „Was“ zu beschreiben, nicht jedoch das „Wie“. Für die tatsächliche Implementierung der gewünschten Funktionalität sind die ...

Die Maven-Alternative?

Apache Buildr

Tammo van Lessen


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. Zudem sind die Konfigurationsoptionen verschiedener Plug-ins nicht immer selbsterklärend und ändern sich mitunter zwischen Plug-in-Versionen. In der Praxis führt dies zu schwer aufzuspürenden Problemen und zu nicht reproduzierbaren Builds. Scherzhaft sprach man sogar vom „Maven Uncertainty Principle“, in Anlehnung an Heisenbergs Unschärferelation.

Notausgänge

Dass dies besser gehen muss, steht außer Frage – aber wo genau liegt eigentlich das Problem? Maven verfolgt einen rein deklarativen Ansatz mithilfe einer XML-basierten DSL. Diese DSL ist allerdings ausschließlich in der Lage, das „Was“ zu beschreiben, nicht jedoch das „Wie“. Für die tatsächliche Implementierung der gewünschten Funktionalität sind die ...

Neugierig geworden?


    
Loading...

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