The Making of an Eclipse Project

Waking up to EclipseLink

Zeb Ford-Reitz

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.

Hibernate musste raus. Und nur um Folgendes klar zu stellen, das Jubula-Team hat nichts gegen Hibernate. Wir haben im GUIdancer-Projekt fünf Jahre lang Hibernate als ORM-(Object-relational-Mapping-)Framework erfolgreich und (verhältnismäßig) glücklich eingesetzt. Aber als 90 Prozent des GUIdancer-Codes als Basis für das neue Eclipse-Projekt Jubula dienen sollte, musste Hibernate leider draußen bleiben. Warum? Eclipse-Projekte müssen unter der Eclipse Public License (EPL) veröffentlicht werden, und Jubula stellt hier keine Ausnahme dar. Hibernate selbst steht unter der GNU Lesser General Public License (LGPL), die inkompatibel zur EPL ist. Obwohl das unser Hauptgrund war, den gesamten ORM Layer der Applikation zu tauschen, gab es noch einen anderen Grund, den wir nicht ignorieren konnten.

Warum keine LGPL?

Obwohl es generell bekannt ist, dass Eclipse-Projekte keinen LGPL-Code einsetzen dürfen (auch nicht als gelinkte Bibliothek), ist es auf den ersten Blick unklar, warum das so ist. Mike Milinkovich hat einen bündigen Blogeintrag zum Thema geschrieben [2]. Dort ist zu lesen, dass die Schwierigkeiten der Eclipse Foundation mit LGPL hauptsächlich in der Unterstützung der kommerziellen Ökosysteme liegen. Dürfte man in Eclipse-Projekten LGPL-Code verwenden, müssten Firmen bei jedem Einsatz von Eclipse-Code oder -Bibliotheken genau prüfen, ob diese im eigenen Produkt lizenzkonform eingesetzt werden dürfen. Die Risiken und der Aufwand dafür würden die Anzahl der Firmen, die Eclipse als Basis für ihr Produkt einsetzen, drastisch reduzieren. Dabei wird die Entwicklung von Eclipse-Projekten entsprechend komplizierter, und Mike Milinkovich nennt auch Fälle, bei denen diese Einschränkung eine Umsetzung als Eclipse-Projekt verhindert hat.

Bundles

Was Eclipse unter anderem zur Rich Client Platform macht, ist die ausgereifte Plug-in-Architektur auf OSGi-Basis. Diese Architektur ist besonders sinnvoll, wenn man mehrere Bundles (oder Plug-ins) einsetzt, die ähnliche oder sogar gleiche Abhängigkeiten besitzen. In diesem Fall kann jede benötigte Bibliothek auch in Form eines Bundles an genau einer Stelle gelagert und gepflegt werden. Wenn die benötigte Bibliothek, in unserem Fall Hibernate, nicht als Bundle vorliegt, dann müsste man diese selber mit ausliefern: entweder als JAR im eigenen Bundle oder als ein selbstständiges Bundle. In beiden Fällen hebelt man die Plug-in-Struktur aus; die Entwickler anderer Bundles wissen nichts von dieser nicht standardmäßig gebündelten Bibliothek und werden sie daher nicht benutzen. Selbst wenn eine solche Abhängigkeit als Bundle realisiert werden kann, muss man wissen, wo dieses Bundle zu finden ist. Folgendes sollte dabei klar sein: Ein Eclipse-Projekt (das in der Regel aus Bundles besteht) ist leichter zu warten, wenn es auf andere Eclipse-Projekte (die ebenfalls aus Bundles bestehen) aufbaut, anstatt sich selber um solche Abhängigkeiten kümmern zu müssen. Des Weiteren freuen sich auch die Nutzer darüber, denn sie müssen keine zusätzlichen P2 Repositories einrichten, um das Bundle zu benutzen.

EclipseLink

Die Suche nach einem neuen ORM-Framework war kurz und schmerzlos. Ein Blick in das Eclipse-Ökosystem genügt, um EclipseLink [3] als ORM-Ablösung für Hibernate ausfindig zu machen. EclipseLink ist seit 2005 ein Eclipse-Projekt. In dem Jahr veröffentlichte Oracle die Kernfunktionen ihres kommerziellen TopLink-Produkts als Open Source. Seitdem baut TopLink auf EclipseLink auf und bietet darüber hinaus erweiterte Funktionen an. Da klingt die Jubula-Geschichte schon fast wie ein alter Hut: Denn auch das Jubula-Projekt, das aus Basiscode von GUIdancer besteht, dient als Open-Source-Basis für seinen kommerziellen „großen Bruder“. Als Eclipse-Projekt erfüllt EclipseLink die beiden notwendigen Kriterien für Jubulas neues ORM-Framework:

  • EclipseLink steht bereits unter der EPL
  • EclipseLink steht als fertiges Bundle im P2 Repository der Eclipse Foundation zur Verfügung.

Das bedeutet, dass man kein weiteres P2 Repository einrichten muss, um Jubula z. B. in einer Eclipse IDE zu installieren. Und nicht nur das, Jubula „spielt“ dadurch auch mit anderen Bundles, die EclipseLink benutzen, problemlos zusammen. Das EclipseLink Bundle wird in den richtigen Versionen an einer Stelle gelagert und gepflegt

Die formalen Kriterien waren somit erfüllt, die technische Umsetzung benötigt noch Etliches an Analyse und Planung.

Geschrieben von
Zeb Ford-Reitz
Kommentare

Schreibe einen Kommentar

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