Die Eclipse Common Build Infrastructure

Bauen mit vereinten Kräften

Markus Knauer

Mit der Eclipse Common Build Infrastructure (CBI) will die Eclipse Foundation eine gemeinsame Basis für Builds der Eclipse-Projekte schaffen. Sie ist die logische Fortführung bekannter Build-Initiativen wie Athena und Minerva und setzt auf existierende Technologien wie Hudson, Git und Maven/Tycho auf.

Ein wenig Namedropping gefällig? Immer wieder liest man im Zusammenhang mit Build-Themen auf den Mailinglisten bei Eclipse.org Begriffe wie Athena, b3, Buckminster, Gerrit, Git, Hudson, Maven, Minerva, Orbit, p2, PDE-Build und Tycho. Sicherlich ist diese lange Liste auch nicht vollständig, wird aber auf jeden Fall in den nächsten Monaten um einen Terminus reicher werden: CBI, die Common Build Infrastructure für Eclipse-Projekte. Doch zunächst ein grober Überblick über die aktuelle Build-Landschaft bei Eclipse.org, wie sie beim jährlichen Simultaneous Release von den Projekten genutzt wird (Abb. 1).

Abb. 1: Übersicht über die Eclipse.org-Build-Umgebung, wie sie von exemplarischen Projekten für das jährliche Simultaneous Release genutzt wird

Starten wir mit dem Sourcecode, der bei Eclipse-Projekten zum Teil noch in CVS liegt; viele Projekte nutzen auch Subversion, andere haben ihren Sourcecode bereits nach Git migriert. Im Gegensatz zum Linux Kernel, der in einem einzigen tar-Archiv vorliegt, müssen bei Eclipse eine Vielzahl an Komponenten in definierten Versionen ausgecheckt und in einem bestimmten Verzeichnislayout im Dateisystem abgelegt werden. Nur dann kann der Build funktionieren. Je nach verwendetem Build-System kommen dabei map–Dateien zum Einsatz (PDE Build wie zum Beispiel in der Eclipse Platform), andere Build-Systeme, wie Buckminster oder Maven/Tycho, verwenden hingegen die dort integrierte Logik für das Dependency-Management zwischen den Komponenten, um den passenden Sourcecode aus den verschiedenen Sourcecode-Management-Systemen (SCM) zu holen und für den Build aufzubereiten. Bis zu diesem Zeitpunkt haben wir uns lediglich um den Sourcecode gekümmert. Es fehlt noch eine definierte Target Platform, gegen die kompiliert werden soll. Im simpelsten Fall besteht der Aufbau der Target Platform im Entpacken von einem oder mehreren ZIP–Archiven, heute ist dies jedoch meist ein dynamisches Zusammenbauen des Targets aus mehreren Quell-p2-Repositories. Oft stößt man an dieser Stelle auf Schwierigkeiten mit Abhängigkeiten zwischen den Projekten. So konsumiert zum Beispiel der Eclipse 4 Platform Build Teile aus den Projekten ECF und EMF. Diese wiederum benötigen eigentlich Teile des Build Outputs der Eclipse Platform. Diese zyklischen Abhängigkeiten versucht man organisatorisch zwischen den Projektteams zu lösen.

Nachdem Sourcecode und Target Platform vorliegen, kann das eigentliche Kompilieren beginnen. Das Ergebnis ist in der Regel ein p2-Repository mit allen Build-Artefakten: Bundles, Features, Binaries und die zugehörigen Metadaten zur Beschreibung der Artefakte. In weiteren Schritten wird dieses p2-Repository noch weiterverarbeitet und optimiert. Dazu gehören das Normalisieren der jar–Dateien zur Pack200-Vorbereitung, das Signieren mit dem Eclipse-Foundation-Zertifikat und das anschließende Optimieren mit Pack200. Die Resultate werden dann von Committern auf den Eclipse-Downloadserver kopiert. Für diese wiederkehrenden Tätigkeiten entwickelt jedes Projekt im Normalfall eigene Skripte, manche werden von Projekt zu Projekt in leicht veränderter Form weitervererbt. Parallel dazu gilt es noch, die unterschiedlichen JUnit Tests und PDE JUnit Tests auszuführen; viele Projekte pflegen auch zusätzliche funktionale und Performancetests.

Was ist nun die Common Build Infrastructure Initiative? Mit der Common Build Infrastructure verfolgt die Eclipse Foundation das Ziel, eine Continuous-Integration-(CI-)Plattform unter Verwendung von existierender Technologie und existierenden Methoden für alle Eclipse-Projekte anzubieten. Somit kann man CBI als evolutionäre Weiterentwicklung der alten Athena Initiative (ursprünglich gedacht als eine Art „Harness“ zur Vereinfachung von PDE Build) und Minerva (ähnlich Athena, nur mit Maven/Tycho als Basis) betrachten.

C wie „Common“

Analysiert man heute fünf verschiedene Projekte bei Eclipse.org, wird man fünf verschiedene Arten finden, wie diese einzelnen Projekte „ihren“ Build implementiert haben. Zyniker werden möglicherweise noch eine sechste Variante ausgraben. Für alle Aufgaben innerhalb des Builds wurden von den Projekten eigene Wege gegangen. So sind in den letzten Jahren eine Vielzahl von Shell-Skripten, Ant-Skripten, Hudson-Jobs und anderen Lösungen entstanden, die allesamt den Vorlieben und Fähigkeiten des jeweiligen Project Release Engineers entsprechen. Sicherlich kann jedes Projekt einzeln betrachtet gute Gründe dafür angeben, warum alles so ist, wie es ist. Auch ist sicher, dass es in jeder Eigenentwicklung einen historisch belegbaren Grund gibt. Dennoch: Summiert man den dafür notwendigen Release-Engineering-Aufwand der Projekte, so kommt man schnell zu dem Ergebnis, dass diese Zeit besser in die Weiterentwicklung der Projektinhalte investiert wäre statt in den Bereich Release Engineering. Gerade neue Projekte bei Eclipse.org scheitern oftmals an dieser zu Beginn immer wieder unterschätzten Hürde und verkennen den tatsächlichen Aufwand, bis ein Projekt einen funktionsfähigen automatischen und reproduzierbaren Build hat. Es gibt aber noch einen weiteren Grund, warum sich dieser Bereich bei Eclipse weiterentwickeln muss. Bei Eclipse.org-Projekten – und dies fällt primär bei den zentralen Kernprojekten ins Gewicht – sind es nur wenige Personen und Firmen, die über die notwendige Erfahrung und über das erforderliche Know-how verfügen, um ein Stück Sourcecode in ein fertiges Produkt zu verwandeln. Diese Abhängigkeit von wenigen Personen und Firmen, bereits bei Closed-Source-Projekten ungünstig, kann bei Open-Source-Projekten langfristig zu einem Hindernis für Innovation werden. Erfolgreiche aktuelle Dienste wie GitHub zeigen, wie wichtig es ist, offen, einladend und attraktiv für andere Entwickler zu sein. Um dies zu erreichen, muss es einfacher werden, in Projekten mitzuwirken und eigenen Sourcecode beizutragen.

Das „Common“ in CBI bedeutet in diesem Zusammenhang also mehreres: Zum einen wird CBI hilfreich sein, indem es neuen Projekten einen standardisierten und erprobten Build-Baukasten anbietet. Zum anderen wird es etablierten Eclipse-Projekten die Möglichkeit geben, ihren eigenen Build zu vereinheitlichen, ihn einfacher reproduzierbar zu machen und damit für andere zu öffnen. Gerade dieser letzte Aspekt macht CBI zu einer Voraussetzung für die Eclipse Long Term Support Initiative (LTS). Erstmalig unabhängig von dritten Personen und Firmen soll CBI das Bauen von Eclipse-Software in einfach– zu reproduzierender Weise auf jedem– Computer ermöglichen. Dies ist ein weiterer wichtiger Baustein für den Erfolg der LTS Initiative, bei der Builds in der kontrollierten Umgebung der Eclipse Foundation Server ermöglicht werden müssen.

B wie „Build“

Beginnen wir mit drei Beispielen, wie Eclipse-Projekte aktuell ihren Build gestalten. Die Eclipse Platform und alle zugehörigen Projekte werden historisch bedingt schon immer mittels PDE Build gebaut. PDE Build besteht streng genommen aus nichts anderem als aus einigen Ant-Skripten, die mittels Konfigurationen weitere Ant-Skripte generieren und diese dann zur Ausführung bringen. PDE Build kann alles, was aus Eclipse-Sicht zum Bau notwendig ist. Es gilt allerdings als Dinosaurier, schwer zu konfigurieren und zu debuggen. Die Athena Initiative versuchte vor einigen Jahren, den Setup-Prozess und die initiale Konfiguration des PDE Builds zu vereinfachen. Darüber hinaus brachte sie noch einige hilfreiche Skripte mit, die beispielsweise den Signierprozess unterstützten.

Eclipse Platform Build CBI Prototype

Betrachten wir zunächst die Art und Weise, wie die Eclipse Platform früher gebaut wurde (Abb. 2):

  1. Auschecken des Quellcodes aus dem Eclipse Foundation CVS auf interne Server bei IBM.
  2. Kompilieren des Quellcodes mit PDE Build, Ausführen von JUnit und Performancetests auf unterschiedlichen Betriebssystemen.
  3. Upload der fertig kompilierten Bundles und Build-Artefakte auf Eclipse Foundation Server in einem großen ZIP-Archiv.
  4. Signieren der Bundles auf einem separaten Server der Eclipse Foundation.
  5. Anschließend Download eines ZIP-Archivs mit den nunmehr signierten Bundles und Build-Artefakten.
  6. Entpacken, Umpacken, Einpacken der Bundles und Build-Artefakte in das, was wir als Platform ZIPs, SDK ZIPs und auch als Platform p2-Repository kennen.
  7. Und – wie könnte es auch anders sein – als letzter Schritt wieder ein Upload all dieser Gigabytes an Daten auf Eclipse Foundation Server.

Zum Glück wurde dieses über die Jahre gewachsene Verfahren seit dem Indigo-Release 2011 geändert. Die Migration des Sourcecode des Eclipse-Platform-Teams nach Git ist seit wenigen Monaten abgeschlossen, und alle Builds laufen auf Eclipse-Foundation-Infrastruktur als PDE Build.

Für die zukünftigen Versionen 4.2 und 3.8 der Eclipse Platform wird zurzeit parallel ein CBI-Build-Prototyp entwickelt (Abb. 3). Grundlage für diesen Build ist nicht wie bisher der PDE Build. Stattdessen kommt die Kombination aus Maven mit Tycho zum Einsatz. Auch wenn der Zugriff darauf noch limitiert ist, kann man unter [2] einen Zugang erhalten. Dort befinden sich auch die aktuellsten Beschreibungen des Build-Vorgangs. Mit einem installierten Java JDK und Maven 3 kommt man mit nur wenigen Kommandos zu einem selbstkompilierten Eclipse Classic SDK. Schon jetzt ist es beeindruckend, wie einfach und schnell man sich damit „sein“ Classic SDK selbst kompilieren kann. Der größte Teil der Zeit wird mit dem Klonen der Git Repositories und mit Maven verbracht, der anschließende Build ist, abhängig von der verwendeten Hardware, nach nur wenigen Minuten fertig.

  • Zunächst wird geprüft, ob die richtige Maven-Version (mindestens 3.0.3) und JDK-Version (1.6) installiert ist. Dann wird zur Vorbereitung ein neues Verzeichnis für den Build erzeugt, und es werden die nativen Teile kopiert. Diese sind zurzeit noch der Eclipse Launcher und der native Part von SWT:

    $ mvn -v

    Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)

    Java version: 1.6.0_23, vendor: Sun Microsystems Inc.

    $ mkdir /var/tmp/lts

    $ cd /var/tmp/lts

    $ rsync -avr @build.eclipse.org:/home/data/users/cbi/natives
    /var/tmp/lts/

  • Mittels Git wird der Sourcecode der Eclipse Platform geklont. Dieser spezielle Branch enthält die notwendigen Anpassungen und die pom.xml-Dateien. Es ist geplant, diese Ergänzungen in den nächsten Wochen und Monaten in die Projekte zurückzugeben und in den Development Stream einzuarbeiten. Der aktuelle Entwicklungsstand ist unter [2] dokumentiert:

    $ git clone -b tycho-monolith-build –recurse-submodules

    @dev.eclipse.org:/home/data/users/cbi/platform-aggregator.git
    R4_platform-aggregator

    $ cd /var/tmp/lts/R4_platform-aggregator

  • Im letzten Schritt wird mit Maven/Tycho das Eclipse Classic SDK kompiliert:

    $ mvn -f eclipse-parent/pom.xml clean install

    -Dmaven.repo.local=/var/tmp/lts/R4_localrepo

    $ mvn clean install

    -Dmaven.repo.local=/var/tmp/lts/R4_localrepo -Dmaven.test.skip=true

Als Ergebnis erhält man zum einen das Eclipse Classic SDK für mehrere Platformen im Verzeichnis TMP/org.eclipse.sdk.epp/target/products/, zum anderen erstellt Maven/Tycho ein p2-Repository mit dem Build-Ergebnis in TMP/org.eclipse.sdk.epp/target/repository/.

Abb. 2: Der Eclipse Platform Build vor dem Indigo-Release

Abb. 3: Der CBI Build Prototype für die Eclipse Platform bzw. das Eclipse Classic SDK Package
Geschrieben von
Markus Knauer
Kommentare

Schreibe einen Kommentar

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