Die flinke Feder

Build Dir Deine Meinung

Was die ASF von anderen Open-Source-Plattformen unterscheidet, ist der Anspruch, für jedes Projekt eine größtmögliche Kontinuität zu gewährleisten. Dazu gehört, dass jedes jemals publizierte Release auch in Zukunft verfügbar sein soll, zusammen mit den Mailing-Listen und den Bug-Trackern. Im Prinzip soll man also noch in zehn Jahren Struts 1 auschecken, bauen und laufen lassen können, wie am ersten Tag. Wenn man das denn will.

Dazu braucht man im Regelfall nicht nur ein JDK, das meist von Sun kommt und aus Lizenzgründen nicht von Apache selbst distribuiert werden darf, sondern auch das entsprechende Build-Tool. Apache-Projekte verwenden beim Bauen, wie viele andere Java-Projekte in der freien Wildbahn, Apache Ant, und neuerdings immer öfter Apache Maven 2. Maven bietet den Vorteil, sämtliche Projektabhängigkeiten aus so genannten Maven Repositories ziehen zu können, ohne dass man sie selbst zusammenklauben muss. Das betrifft sowohl Build-Funktionalität („Maven-Plug-ins“), als auch die eigentlichen Libraries, die von der gebauten Software benötigt werden, z. B. JUnit, Logging-Framework-JARs und Container-Libraries. Die Abhängigkeiten werden in pom.xml-Files deklariert und beim Bauen heruntergeladen. Maven löst automatisch transiente Abhängigkeiten auf, was oftmals einen wahren Rattenschwanz an teilweise obskuren Downloads nach sich zieht. Wer kann schon spontan sagen, was das „Surefire-Plug-in“ macht oder warum Libs wie village.jar oder activation.jar angezogen werden müssen?! (Hier kann übrigens mvn dependency:tree für Aufschluss sorgen.) Die Build-Tools wurden im letzten Java Magazin ausführlich betrachtet.

Kann die Abhängigkeit über kein Repository (mehr) aufgelöst werden, so ist guter Rat teuer – und ein Build erst einmal unmöglich. Je mehr man aus Mavens Werkzeugkiste nutzt, desto mehr reduziert sich der Grad, indem alle Informationen, die für das Projekt benötigt werden auch am Projekt selbst gespeichert werden. Das kann für ein Open-Source-Projekt mit exotischen Abhängigkeiten im Extremfall bedeuten, dass es nicht mehr aus einem frischen Checkout heraus gebaut werden kann. Und das ist schlecht. Denn im Gegensatz zum eigenen In-House-Projekt, wo man das fehlende JAR vielleicht im eigenen Fundus noch auftreiben kann, wird der freie Nutzer freier Software sich die Freiheit nehmen, sich von unge-Build-eten Projekten abzuwenden.

Wir sind Abhängige von freier Software – auch im schlechten Sinne. Abhängig davon, dass uns Suns (pardon: Oracles) JVM umsonst zur Verfügung steht, abhängig davon, dass Apache Tomcat Sicherheits-Patches bekommt, darauf angewiesen, dass unser Ant-Lauf auch auf dem nächsten Linux Kernel oder Windows 8½ noch startet.

Diese Tatsache wurde kürzlich deutlich, als Jason van Zyl, Entwickler bei Maven, dazu aufrief, die Maven Repositories von java.net zu retten. Es macht schon Sinn, Open-Source-Projekte so zu organisieren, dass sie möglichst viele ihrer Abhängigkeiten selbst bunkern. „Nachhaltigkeit“ ist der Begriff, der mir dazu einfällt.

Van Zyls Empfehlung lautet: Repository Server, die man sich ins Unternehmen stellt und die als Verbindungsstelle zwischen lokalem Build und entferntem Repository stehen. Seine Firma hat entsprechendes im Portfolio. Und auch bei Apache findet sich eine solche Installation.

Entfernte Repository-Dienste, die einem die benötigten JARs liefern, werden de-facto nicht immer und in alle Ewigkeit verfügbar sein. Wer besorgt deren Backups? Hoffentlich irgendjemand! Zumindest bei Apache ist das der Fall. Geplant ist: für alle Zeiten.

Abhängigkeiten selbst vorzuhalten, wird für Apache-Projekte grundsätzlich nur da schwierig, wo eine Dependency zu Software mit inkompatibler Lizenz (z. B. GPL, oder Closed Source) besteht. Solche können nur „lose“, über ein fremdes Repository oder händischen Download des Nutzers aufgelöst werden. Ins Apache-SVN dürfen sie nicht eingecheckt werden, und distribuiert schon gar nicht.

Innerhalb der Apache-Projekte wird das Thema Maven versus Ant eifrig diskutiert. Dabei lässt sich derzeit eine klare Tendenz zu Maven feststellen. Unsere tagtägliche Arbeit vereinfacht sich durch den Convention-over-Configuration-Ansatz radikal – doch die Nachhaltigkeit der Builds muss im Auge behalten werden.

 

Bernd Fondermann (bernd.fondermann@brainlounge.de) ist freiberuflicher Softwarearchitekt und Consultant in Frankfurt a. M. Er beschäftigt sich mit innovativen Open-Source-Technologien wie Apache Hadoop und Lucene und ist Member der Apache Software Foundation und Vice President Apache Labs.
Geschrieben von
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.