Die Eclipse Common Build Infrastructure

Bauen mit vereinten Kräften

Markus Knauer

Als zweites Beispiel dient das Eclipse Packaging Project (EPP) mit Buckminster. EPP baut sämtliche Pakete, die von der Eclipse.org-Downloadseite heruntergeladen werden können. Hierbei kommt Buckminster für das Erzeugen der Branding-Plug-ins, der Features und der Metadaten zum Einsatz. Aus diesen werden dann in einem zweiten Schritt mittels p2 Director die einzelnen Pakete assembliert. Das hier verwendete Buckminster ist nach PDE Build die zweite Technologie, die von vielen Eclipse-Projekten eingesetzt wird. Es wurde als Build-Tool speziell für komponentenorientierte Software entworfen und versteht Abhängigkeiten zwischen Bundles und typischen Eclipse-Artefakten, kann also mit MANIFEST.MF ebenso gut umgehen wie mit einer feature.xml oder einer RCP-Produktdefinition.

Gerade neue Projekte wie zum Beispiel das Eclipse Runtime Packaging Project (RTP) haben sich jedoch im letzten Jahr meist dazu entschlossen, ihren Build mit der dritten populären Build-Technologie, einem Team aus Maven 3.0 und Tycho, zu realisieren. In diesem Fall enthält jedes Projekt die dafür notwendige Maven-typische pom.xml-Datei. Tycho ist dafür zuständig, Maven beizubringen, wie es mit einer MANIFEST.MF umzugehen hat und wie das Ergebnis zu paketieren ist (Plug-ins/Bundles, Features, p2-Repositories, RCP-Applikationen). Wie auch schon beim PDE Build gibt es hier den Versuch der Vereinfachung. Was die Athena Initiative für PDE Build war, ist nun Minerva für Maven/Tycho. Minerva stellt einen einfacheren Einstieg in den Maven/Tycho Build bei Eclipse.org zur Verfügung. Erwähnenswert ist weiterhin, dass es für die Eclipse-Projekte ein einheitliches Parent-POM gibt, das Gemeinsamkeiten für alle Eclipse-Projekte vordefiniert. Für die Common Build Infrastructure hat man sich entschieden, diese anhand von Maven/Tycho zu implementieren. Eine Rolle bei dieser Entscheidung spielte die Tatsache, dass diese Maven/Tycho Builds sowohl auf Servern der Eclipse Foundation als auch auf lokalen Workstations ohne Änderungen lauffähig sind.

Die bisher beschriebenen Technologien betreffen einzelne Projekte. Betrachtet man darüber hinaus das jährliche Simultaneous Release, so fehlt noch ein weiteres Puzzlestück. Auch für das Juno-Release 2012 wird es wieder ein aggregiertes p2-Repository mit den Ergebnissen der teilnehmenden Projekte geben. Für Konsumenten erleichtert dies das Installieren neuer Software und die Aktualisierung bestehender Eclipse-Installationen. Für die Produzenten, also die Eclipse-Teams, ist hingegen der Build-Prozess interessant (Abb. 1). Jedes Projekt stellt seine Artefakte als p2-Repository zur Verfügung. Der Aggregator aus dem b3-Projekt ist dafür verantwortlich, definierte Artefakte aus den projektspezifischen p2-Repositories in das Simultaneous Release p2-Repository zu aggregieren, und erstellt dort die Metadaten und die Kategorien für die installierbaren Einheiten. Erst damit entsteht das „Release Train Repository“, wie wir es kennen.

I wie „Infrastructure“

Seit ein paar Jahren gibt es den Continuous Integration Server Hudson für Eclipse.org-Projekte. Begonnen hatte alles damit, dass einige Committer unzufrieden damit waren, ihre Builds von Hand anzustoßen oder als Cron Job laufen zu lassen. Einige Committer entschieden sich für CruiseControl, andere betrieben zunächst in Eigenregie die Konkurrenz Hudson. Über die Zeit hinweg wurde dieser Community-managed Hudson so populär und wichtig, dass die Eclipse Foundation den Regelbetrieb übernahm und mit verschiedenen Hardwarespenden ein Hudson-Cluster aufbauen konnte. Dieses umfasst auch Betriebssysteme wie Mac OSX, Windows 7 sowie verschiedene Linux-Versionen auf Basis der Hardwareplattformen X86, IA64 und PPC. Durch diese breit gefächerte Infrastruktur können auch betriebssystem- oder hardwarespezifische Tests ausgeführt werden. Der Continuous Integration Service basierend auf Hudson ist somit zentraler Bestandteil der Common Build Infrastructure.

Abb. 4: Hudson Server bei der Eclipse Foundation mit den unterschiedlichen Hudson Slaves

Git ist mittlerweile das favorisierte Sourcecode-Management-System bei Eclipse.org, was vor zwei Jahren noch anders war: Es gab nur die Wahl zwischen CVS und Subversion, wobei letzteres in der Eclipse-Community nie besonders großen Anklang fand. Damals war es sogar überaus schwer, die notwendige Überzeugungsarbeit für die Einführung eines dritten SCM zu leisten. Mittlerweile sind die Tage von CVS gezählt, und es wird gegen Ende 2012 in den Read-Only-Modus versetzt werden (zum aktuellen Migrationsstatus siehe [3]). Bis dahin müssen alle CVS-Projekte migriert sein; für die noch existierenden Subversion-Projekte zeichnet sich die gleiche Entwicklung ab. Wer sich mit Git beschäftigt, kommt früher oder später mit Gerrit in Kontakt. So ist es kein Wunder, dass letzteres, getrieben durch die Community und einige Vorreiterprojekte, ein Thema bei der Eclipse Foundation geworden ist und seit Februar der Eclipse Gerrit Server für alle Projekte zur Verfügung steht [4].

Ein paar Bausteine fehlen noch zu einem vollständigen Bild der Infrastruktur. Gerrit mag für viele Projekte die Zukunft sein, WIE Sourcecode in das SCM kommt – die Frage nach dem WARUM beziehungsweise dem Change Control wird weiterhin über Bugzilla beantwortet werden können. Dies zur Seite des Inputs, bleibt noch die Frage des Outputs. Die gebauten Build-Artefakte landen entweder als fertig paketierte Einheiten – wie zum Beispiel die EPP-Pakete von eclipse.org/downloads – oder als p2-Repository auf dem Eclipse.org-Downloadserver und werden von dort weltweit auf die Mirrors verteilt, von wo sie dann jedem zur Verfügung stehen. Um überprüfen zu können, ob dieser Inhalt unverändert ist und von Eclipse.org stammt, sollten jar-Dateien signiert sein. Hierfür wird von der Eclipse Foundation ein von der restlichen Infrastruktur abgetrennter Signing-Server mit dem Eclipse-Foundation-Zertifikat betrieben, das von Eclipse-Projekten zur Signierung ihrer Build-Artefakte genutzt wird. Projekte, die die Common Build Infrastructure verwenden, kommen zukünftig auf einfache Weise in den Genuss signierter Builds, ohne die bisher notwendigen Skripte manuell erstellen und pflegen zu müssen, da Builds direkt mit Maven signiert werden können.

Status und Ausblick

Viele Komponenten der Common Build Infrastructure bestehen schon und müssen teils nur noch leicht erweitert, teils nur noch angepasst und als Best Practice dokumentiert werden. CBI ist ganz sicher keine Revolution, sondern eher eine Evolution basierend auf den Lessons Learned und Best Practices aus Athena, Minerva und anderen Projekten. Neben dem Plan, den Prototyp des Eclipse Classic/SDK Builds zu vervollständigen, existieren zurzeit auch Pläne, alle anderen EPP-Pakete im Rahmen des Juno-Release auf CBI zu migrieren. Wer in den nächsten Monaten die Weiterentwicklung der CBI aus erster Hand weiterverfolgen will, sollte sich bei der CBI-Developer-Mailingliste [5] registrieren.

Markus Knauer arbeitet als Eclipse-Entwickler und Consultant bei EclipseSource. Er leitet das Eclipse Packaging Project (EPP), ist Co-Project Lead des g-Eclipse-Projekts sowie Mitglied des Eclipse Planning Councils und des Eclipse Architecture Councils.
Geschrieben von
Markus Knauer
Kommentare

Schreibe einen Kommentar

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