Suche
The Making of an Eclipse Project

Open Sourcing & Release Engineering @ Eclipse.org

Markus Tiede

Was steckt eigentlich hinter einem Eclipse-Projekt? Welche Entscheidungen sind zu treffen, welche Bedingungen zu erfüllen, wie läuft das alles? Das Eclipse-Jubula-Team berichtet in loser Folge über seine Erfahrung beim Open Sourcing von Jubula [1]. Dabei geht es nicht nur um Technik, sondern auch um Strategien, Abläufe und schwierige Entscheidungen.

Der letzte Teil dieser Kolumne zum Thema „Jubulas Erfahrungen auf dem Weg in die Open-Source-Welt“ soll konkrete Schritte aufzeigen, die nötig gewesen sind, um ein Projekt unter den Fittichen der Eclipse Foundation zu veröffentlichen. Der Ausdruck „veröffentlichen“ ist dabei in mehrfacher Hinsicht zu verstehen: angefangen vom simplen Bereitstellen des Quellcodes für die Allgemeinheit, über das Aufsetzen eines Continuous Builds, bis hin zur Erzeugung von Eclipse-konformen Artefakten und der Teilname am so genannten „Release Train“. In den drei bereits erschienenen Folgen dieser Reihe haben wir schon Themen wie den „ersten Einstieg“, den rechtlich notwendigen „Intellectual Property (IP)“-Prozess der Eclipse Foundation und den Einsatz von „EclipseLink“ als OR-Mapper beleuchtet. Dieser Teil fokussiert daher weniger auf das rechtliche „Drumherum“, vielmehr soll er konkrete Arbeitsschritte und Verantwortlichkeiten aufzeigen, die einen Entwickler erwarten, wenn er sich auf das Abenteuer „Eclipse-Projekt“ einlässt.

Open your Source

Was sich wie eine Selbstverständlichkeit anhört, nämlich dass ein Open-Source-Projekt öffentlich zugängliche Quellen besitzt, war für uns anfänglich mit einem nicht zu unterschätzenden Aufwand verbunden. Denn nur zu leicht lässt man sich dazu verleiten, den eigentlichen Schritt, seinen Quellcode zu veröffentlichen, auf den einmaligen „Commit“ desselbigen zu reduzieren. Tatsächlich war aber einiges an Vorarbeit zu leisten. An dieser Stelle möchten wir aber schon klarstellen, dass dies längst nicht auf jedes neue Projekt zutreffen muss. Jubula stellt insofern eine Sondersituation dar, als dass es nicht wirklich als neu einzustufen ist. Wir haben uns gegen Ende 2010 dazu entschieden, weite Teile des jahrelang schon bestehenden kommerziellen Produktes GUIdancers unter dem Projekt Jubula zu veröffentlichen. Somit gab es bereits eine massiv über die Jahre gewachsene Codebasis (> 350k LoC), die für eine Veröffentlichung zuerst vorbereitet werden musste.

Neben dem notwendigen Papierkram um alle rechtlichen Vorgaben zu erfüllen (siehe Teil 2 und Teil 3 der Serie), stand am Anfang dieser Vorbereitung eine hochsensible wenn auch teilweise stumpfsinnige Aufgabe. Dies war die korrekte namentliche Abgrenzung der Teile, die der Open-Source-Welt zugeführt werden sollten – auf gut Deutsch eine Umbenennung. Dieser Schritt war von unterschiedlicher Motivation getrieben:

  • Zuallererst sollte es eine klare Abgrenzung zum bereits bestehenden Produkt darstellen um Verwechslungen vorzubeugen und eine eindeutige Zuordnung zu gewährleisten.
  • Ein weiteres Ziel war die Schaffung einer einheitlichen Terminologie für interne und potenzielle externe Committer und Contributer. Da das Projekt bereits jahrelang gewachsen war, und sich dabei sukzessiv bestimmte, zum Teil auch unterschiedliche und mehrdeutige, firmeninterne Terminologien entwickelt hatten, war es zwingend erforderlich diese zu vereinheitlichen um eine gemeinsame sprachliche Basis zu schaffen.
  • Nicht zuletzt hatte diese Umbenennung auch einen rechtlichen Hintergrund: Jedes Eclipse zugehörige Projekt muss in den vielfältigen Qualifiern, die es gerade im RCP-Umfeld gibt, das Präfix „org.eclipse.*“ tragen. Angefangen von Java-Paketnamen, über OSGi-Bundle-Namen, Extension [Point] IDs bis hin zu Feature- und Produktbezeichnungen.

Heutige IDEs bieten vielfältige Möglichkeiten für ein solches Refactoring und unterstützen den Entwickler erheblich bei der Durchführung solcher mitunter sehr weit reichender Änderungen. Gesagt, getan – etwa eine Mannwoche später war die Umbenennung der ca. 70 Bundles und deren Inhalt vollbracht. Echte Stolpersteine gab es nur in Bereichen, in denen die Änderungen erst zur Laufzeit sichtbar wurden, wie beispielsweise bei Verwendung des Java Reflection API zum dynamischen Laden und Instanziieren von Klassen.

Alle Dateien zusammen wurden dann als ein einziges ZIP als Anhang an einen IPZilla Bug gehängt und in Form eines CQ (Contribution Questionnaire) an den Eclipse IP Check übergeben. Nach kurzer, eingehender, automatisierter Prüfung befanden wir uns in der so genannten Inkubationsphase. Jetzt war es uns bereits erlaubt, den Quellcode und was sonst noch so dazu gehört, der Allgemeinheit in einem öffentlichen Versionsverwaltungssystem zugänglich zu machen.

Git it right

Die Frage, was es zu veröffentlichen gab, war von diesem Zeitpunkt an geklärt, die Frage nach dem Wie hingegen noch offen. Firmenintern etabliert war und ist seit Langem das Versionsverwaltungssystem Subversion. Einschlägig bekannt und durch diverses Tooling im Eclipse-Umfeld unterstützt, hat es seine Alltagstauglichkeit bereits dutzende Male unter Beweis gestellt.

Der neue Quasi-Standard in Hinblick auf Versionsverwaltung und Quellcodemanagement im Eclipse-Umfeld trägt aber den Namen EGit bzw. JGit [3]. Also hieß es für uns umsatteln und eintauchen in die Welt von Git. Wir wollen an dieser Stelle keine Einführung in das Arbeiten mit Git geben, sehr wohl aber ein kurzes Fazit unseres Einsatzes innerhalb der letzten zwölf Monate ziehen. Git arbeitet sehr zuverlässig und vor allem schnell: Bedenkt man, dass ein jedes lokales Repository eine vollständige Kopie des Ursprungs-Repositorys ist. Zu jeder Zeit hat man immer und überall sein komplettes Repository dabei, inklusive der vollen Historie. Der technische Umstieg vom alten SVN auf das neue Git Repository war problemlos möglich, nicht zuletzt deshalb, weil wir darauf verzichtet haben, die gesamte SVN-Historie zu portieren. Der fachliche Umstieg hingegen ist ein kontinuierlicher Prozess und selbst nach der verhältnismäßig langen Zeit noch nicht abgeschlossen (Selbsteinschätzung des Autors). Bis man die Arbeit mit Git wirklich beherrscht und vollständig von seiner Mächtigkeit profitiert, muss man sich Zeit lassen. Erste Schritte wie das „Committen“ und „Pushen“ gelingen aber schon nach wenigen Minuten.

Geschrieben von
Markus Tiede
Kommentare

Schreibe einen Kommentar

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