Open Sourcing and Release Engineering @ Eclipse.org

Strict Constraints

An diesem Punkt angelangt mussten wir schnell feststellen, dass das alleinige Bereitstellen von öffentlichem Quellcode aber längst nicht alles ist, was ein Eclipse-Projekt für den Release Train tauglich macht. Eine Reihe von Anforderungen [4] des Release Trains zielen konkret auf einen stabilen und erwachsenen Build-Prozess und dessen Artefakte ab (beispielsweise JARs und ZIPs). Das Bauen der Artefakte muss dokumentiert, automatisiert, wiederholbar und auch von Dritten durchführbar sein. Und auch die entstehenden Artefakte müssen eine ganze Reihe von Eigenschaften erfüllen:

  • Alle Bundles müssen als JAR vorliegen und das OSGi-Bundle-Format mit einem MANIFEST.MF besitzen.
  • Sie müssen darüber hinaus ihre minimale Laufzeitumgebung definieren (Bundle Required Execution Environment, BREE) und Gebrauch von vierstelligen Versionsnummern machen.
  • Gebündelt werden sollen alle Artefakte (Features und Bundles) in p2 Repositories
  • Jegliche Artefakte, die im Namen der Eclipse Foundation veröffentlich werden, müssen mit dem entsprechenden Eclipse-Zertifikat signiert sein.

Zwar hatten wir zu diesem Zeitpunkt einen bereits seit Langem etablierten Build-Prozess, doch wurde uns schnell klar, dass dieser – galant ausgedrückt – eine hohe Affinität zur lokalen Firmeninfrastruktur besaß. Diese konnten wir unmöglich der Allgemeinheit zugänglich machen. Darüber hinaus können Artefakte nur in der internen Build-Infrastruktur der Eclipse Foundation signiert werden. Die Herausgabe dieser Zertifikate ist nicht möglich. Von daher mussten wir uns schnell von dem Gedanken verabschieden, die für den Release Train benötigten Artefakte lokal vor Ort zu bauen. Auch hier hieß es wiederum Neuland betreten: die Auslagerung der kompletten Build-Infrastruktur auf die Rechner der Eclipse Foundation.

Eclipse-Release Train

Unter dem Eclipse Release Train versteht man die Zusammenarbeit aller teilnehmenden Projekte auf den einen Tag hin – den vierten Mittwoch im Juni eines jeden Jahres – an dem die neue Eclipse-„Hauptversion“ erscheint. Da für diese Zusammenarbeit häufig eine treibende externe Kraft von Nöten ist, die dafür sorgt, dass alle Projekte in der Spur bleiben, liegt die Analogie zum Betrieb eines Zuges sehr nah.

„Toi, toi, toi“ – 2011 war das achte Jahr in Folge, in dem die Eclipse Foundation mit tagesgenauer Pünktlichkeit die Freigabe des neuen Release verkünden konnte.

Remote and local Builds

Dieses Auskundschaften neuer Territorien hat anfangs häufig in eine nicht tragfähige Sackgasse geführt. Aus diesem Grund möchten wir an dieser Stelle die Evaluationsdetails verschiedener Build-Mechanismen überspringen und gleich unseren final verwendeten Lösungsansatz aufzeigen. Jubula wird mit einer Kombination aus Maven3 und Tycho (und einigen wenigen ANT- und Shell-Skripten) in der Hudson-CI-Infrastruktur [5] jeden Tag aufs Neue gebaut. Diese Variante hat sich als sehr flexibel herausgestellt. Das ausgereifte automatische Dependency-Management von Maven in Verbindung mit der Mächtigkeit von Tycho war für uns der entscheidende Faktor. Mit Tycho ist es sehr leicht möglich, diverse Arten von Eclipse-spezifischen Artefakten zu erzeugen. Denn einerseits wollen wir den Build-Prozess zwar primär in der Eclipse-Infrastruktur betreiben, andererseits es uns jedoch nicht vorenthalten, auch alle benötigten Artefakte weiterhin lokal in unserer Infrastruktur bauen zu können. Und nicht selten haben wir von diesem Fallback im letzten Jahr, beispielsweise bei auftretenden Problemen im entfernten Rechenzentrum, schon Gebrauch machen müssen. Diese Kombination lässt es jetzt ohne großen Mehraufwand zu, Folgendes in zwei verschiedenen Infrastrukturen bauen zu können:

  • 70 Bundles
  • drei Features
  • verschiedene p2 Repositories
  • diverse unterschiedliche Konfigurationen wie Version und Umfang

In Listing 1 wollen wir zeigen, wie eine solche Bundle-Build-Konfiguration in Maven auszusehen hat. Dank des engen Zusammenspiels von Maven und Tycho fällt diese nämlich erstaunlich übersichtlich aus.

Listing 1
4.0.0org.eclipse.jubula.releng.clientorg.eclipse.jubula1.1.0-SNAPSHOT../org.eclipse.jubula.releng.clientorg.eclipse.jubulaorg.eclipse.jubula.client.ui1.1.0-SNAPSHOTeclipse-plugin

Diese Konfiguration reicht bereits aus, eines unserer größten Bundles zu bauen. Der spannende Teil lässt sich sogar auf <packaging>eclipse-plugin</packaging> reduzieren. Diese Option in Verbindung mit einem mvn clean verify auf der Kommandozeile genügt Maven/Tycho Folgendes mitzuteilen:

  • Zuerst alle vorhandenen alten Build-Artefakte aufräumen.
  • Dann die Abhängigkeiten zu weiteren Bundles transitiv auflösen.
  • 3rd-Party-Bibliotheken, welche sich beispielsweise auf dem Runtime Classpath befinden, neben den Bundle-Abhängigkeiten mit auf den Compile Classpath nehmen.
  • Compiler-Einstellungen aus den bereits im Bundle definierten OSGi/Equinox-Metadaten wie dem MANIFEST.MF und build.properties ziehen.
  • Alle Klassen aus dem src-Verzeichnis kompilieren.
  • Alle benötigten Teilartefakte des Bundles in Form eines JARs zusammenfassen.
  • Gegebenenfalls existierende Unit Tests ausführen.

Alle weiteren Details zum Build-Prozess können direkt im öffentlichen Repository [6] eingesehen werden – in über 90% der Fälle beläuft es sich aber auf die zuvor beschriebene POM-Konfiguration eines Projektes.

Auch hier noch eine kleine Anmerkung zum entstandenen Aufwand: Nach abgeschlossener Evaluation des zu beschreitenden Weges hat die Umstellung und Migration ungefähr drei Mannwochen in Anspruch genommen. Denn trotz der hohen Redundanzvermeidung und übersichtlichen Konfiguration, die Maven und Tycho erlauben, steckt der Teufel dann manchmal doch im Detail. Als Stichworte seien hier beispielweise statisches Bytecode-Weaving für das JPA „lazy-loading“, die Generierung von Lexern und Parsern und die automatische Erzeugung und Konvertierung von Onlinehilfeinhalten genannt.

Do no Harm but do it early

Trotz siebenmonatiger Vorlaufzeit haben wir im Nachhinein betrachtet „auf den letzten Drücker“ am Indigo-Release-Train teilgenommen. Denn neben der Vielzahl an rechtlichen und technischen Vorraussetzungen gab es noch eine Reihe von Deadlines, die es einzuhalten galt. Bereits elf Monate vor den jährlichen Eclipse-Releases beginnen die ersten Integrationszyklen in Form von Aggregations- und Packaging-Läufen. Inzwischen nehmen mehr als 60 Projekte am Release Train teil und damit diese in der finalen Version alle entsprechend gut miteinander harmonieren und „friedlich“ nebeneinander laufen, ist frühes Testen angesagt. Diese anfänglich monatlichen Milestones und später wöchentlichen „Release Candidates“ besitzen dabei fest definierte Zeiten. Zwar ist die Teilnahme anfänglich nicht verpflichtend, aber trotzdem sehr empfehlenswert. Denn findet man ein Problem beim Zusammenspiel der einzelnen Komponenten, dauert es mitunter einige Zeit bis das Problem behoben werden kann.

And now?

Abschließend lässt sich sagen, dass es in der Tat ein Abenteuer war, diesen Weg in die Open-Source-Welt zu beschreiten. Nicht immer war man sich sicher, wohin der nächste Schritt zu setzen war. Wir hoffen aber, dass diese Kolumne dazu beitragen konnte, ein wenig Licht ins Dunkle zu bringen. Trotz aller etwaiger Startschwierigkeiten hat sich der Schritt für uns in vielerlei Hinsicht bereits jetzt gelohnt. Denn die große Menge an Feedback und die hohe Anzahl an interessierten neuen Anwendern sprechen für sich. Zeit zum Ausruhen bleibt ebenfalls nicht – das im Juni 2012 erscheinende Juno-Release nähert sich mit großen Schritten. Und auch dort wollen wir wieder mit einer Reihe toller Neuigkeiten eine Jubula-Version veröffentlichen.

Markus Tiede ist Eclipse Committer im UI-Testautomatisierungsprojekt Jubula und Package Maintainer für „Eclipse for Testers“. Als Entwickler und Tester bei der BREDEX GmbH ist er seit 2008 auch an Jubulas kommerziellem „großem Bruder“ GUIdancer beteiligt.
Kommentare

Schreibe einen Kommentar

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