Kolumne: EE Insights

Proposal, Prüfung & Prozesse: Warum dauert der Umzug von Jakarta EE so lange?

Christian Kaltepoth

Der Tod von Java EE ist schon häufig prophezeit worden. Doch dann kam alles anders und es passierte, was wohl niemand für möglich gehalten hat. Oracle kündigte an, Java EE an die Eclipse Foundation zu übergeben. Der eigentliche Transfer wurde Ende 2017 eingeleitet, also vor über einem Jahr. Grund genug einmal genauer zu betrachten, was seit Beginn der Übergabe passiert ist und wie die Inkubationsphase bei der Eclipse Foundation im Detail abläuft.

Christian Kaltepoth

Das neue Zuhause von Java EE ist das Eclipse-EE4J-Projekt. Bei EE4J handelt es sich um ein sogenanntes Top-Level-Projekt, welches wiederum aus einer Reihe von Unterprojekten besteht. Im Falle von EE4J sind das die Spezifikationen, deren Referenzimplementierungen, das jeweilige Java EE TCK, Eclipse Glassfish und einige weitere Projekt. Ein Eclipse-Top-Level-Projekt definiert in einer „Charta“ Ziele und Regeln für die teilnehmenden Projekte. An der Spitze eines Top-Level-Projekts steht das Project Management Committee (PMC), dessen Aufgabe es ist, über die korrekte Anwendung des Eclipse Developer Process (EDP) und der Charta zu wachen.

Andere Owner, andere Sitten

Der erste Schritt für ein neues Projekt ist immer die Erstellung des „Project Proposal“. Dieses Dokument dient dazu, das Projekt im Detail zu beschreiben. Welche Ziele setzt sich das Projekt, welche Lizenz soll verwendet werden, wie grenzt es sich von anderen Projekten ab und weitere Fragen werden darin beantwortet. Bestandteil des Vorschlags sind auch die anfänglichen Projektleiter, die Committer und die Mentoren der Eclipse Foundation. Oracle hat Ende 2017 damit begonnen, die Proposals der ersten Java-EE-Projekte einzureichen. Wie nicht anders zu erwarten, hat dieser Prozess bei über 40 Projekten in Summe recht lange gedauert, sodass die letzten Proposals erst im Frühjahr 2018 veröffentlicht wurden.

Die erste Phase für ein neues Projekt nennt sich „Community Review“ und dauert mindestens zwei Wochen. Wie der Name bereits vermuten lässt, dient diese Phase dazu, Feedback der Community zu sammeln, durch welches das Proposal eventuell angepasst werden kann. Gleichzeitig beginnt auch auf Seite der Eclipse Foundation eine genauere Begutachtung des Projektvorschlags. So wird beispielsweise geprüft, ob die geplante Lizenz rechtlich möglich ist und inwieweit der Name des Projekts bezüglich potentiell existierender Trademarks von Dritten problematisch sein könnte. Vor allem die Markenrecherche kann erfahrungsgemäß recht zeitaufwendig sein, ist aber eine zwingende Voraussetzung, damit das Projekt von Anfang an rechtlich auf solidem Boden steht. Auch die Ergebnisse dieser Prüfungen fließen wieder in das Proposal ein, sodass es zu diesem Zeitpunkt theoretisch noch zu Änderungen kommen kann.

Im Anschluss an das Community Review findet das so genannte „Creation Review“ durch die Eclipse Foundation statt. Dieser Schritt ist eigentlich Formsache und daher in den meisten Fällen erfolgreich. Ist auch diese Hürde überstanden, beginnt die Phase der Provisionierung. Das bedeutet konkret, dass die für das Projekt benötigte technische Infrastruktur vorbereitet wird. Dazu gehört beispielsweise ein eigener Bereich auf der Eclipse Homepage, eine oder mehrere Mailing-Listen für Entwickler und Benutzer, das Git Repository und der Issue Tracker. Im Falle der EE4J-Projekte wurde statt der Eclipse eigenen Git/Gerrit/Bugzilla-Infrastruktur auf GitHub zurückgegriffen. Alle EE4J-Projekte finden sich unterhalb der GitHub-Organisation eclipse-ee4j und sind somit für jeden leicht zu finden. Die Entscheidung für GitHub zur Verwaltung des Quellcodes und der Tickets fiel leicht, da nach der Schließung von java.net Anfang 2017 bereits die meisten Projekte zu GitHub migriert worden sind.

Just a little git push?

Wer jetzt denkt, dass mit der Provisionierung der Git Repositorys die produktive Arbeit an den Projekten losgehen kann, liegt allerdings falsch. Einer der wichtigsten und zeitaufwendigsten Schritte fehlt noch, nämlich die Migration des existierenden Quellcodes zur Eclipse Foundation. Leider ist diese Aufgabe nicht mit einem einfachen git push getan.

Der an die Eclipse Foundation zu übertragene existierende Quellcode wird als „Initial Contribution“ bezeichnet. Bevor dieser Code in die zuvor erstellten Git Repositorys übertragen werden darf, wird er vom IP-Team der Eclipse Foundation genau geprüft. Ein zentraler Bestandteil dieser Analyse ist dabei herauszufinden, inwieweit die Übertragung des Quellcodes an die Eclipse Foundation aus Sicht des Urheberrechtes unbedenklich ist. Dazu ist beispielsweise zu klären wer die Autoren des Quellcodes sind, unter welcher Lizenz das Projekt bisher stand, welche patentrechtlichen Aspekte eventuell noch berücksichtigt werden müssen und vieles mehr.

Bei großen Projekten wie beispielsweise Jersey oder Mojarra ist diese Aufgabe natürlich alles andere als trivial. Aus diesem Grunde wird im Rahmen der Initial Contribution auch nicht die vollständige Historie des Quellcodes übertragen, sondern lediglich der aktuelle Stand. Das ist zwar in gewisser Weise nicht gerade optimal, weil sich in der Historie der Versionskontrolle ja auch durchaus wichtige Informationen wiederfinden, allerdings wäre eine komplette Prüfung der gesamten Geschichte des Quellcodes alles andere als praktikabel und würde sehr viel mehr Zeit in Anspruch nehmen. Spätestens jetzt wird klar, warum Oracle in der Vergangenheit für jedes eingereichte Patch die Unterzeichnung des „Oracle Contributor Agreements“ gefordert hat. Genau dieses Agreement erlaubt es Oracle nämlich, eine solchen Transfer überhaupt erst durchzuführen.

Nachdem das Eclipse IP-Team die Initial Contribution abgesegnet hat, darf diese in die Versionskontrolle eingespielt werden. Theoretisch kann ab diesem Zeitpunkt mit der aktiven Arbeit am Projekt begonnen werden. Allerdings schließt sich parallel dazu ein weiterer Schritt an, der ebenso sehr aufwendig sein kann: Zwar ist die rechtliche Prüfung des Quellcodes zu diesem Zeitpunkt abgeschlossen, jedoch kommt bekanntlich kaum ein Projekt ohne Abhängigkeiten zu Drittbibliotheken aus. Auch hier spielt das Urheberrecht und vor allem die jeweiligen Lizenzen der Bibliotheken eine wesentliche Rolle. Verwendet das Eclipse-Projekt wie im Falle von EE4J die Eclipse Public License (EPL), so ist beispielsweise die Nutzung einer Bibliothek mit GPL-Lizenz nicht möglich, da diese mit der EPL inkompatibel ist. Für alle Abhängigkeiten der neunen Eclipse-Projekte muss somit geprüft werden, inwieweit die verwendeten Bibliotheken kompatible Lizenzen verwenden. Was genau wie die Prüfung der Initial Contribution nach einem sehr aufwendigen Prozess klingt, ist allerdings notwendig, damit aus lizenzrechtlicher Sicht eine klare Situation herrscht, was wiederum für die Endnutzer der Projekte von zentraler Bedeutung ist, da Abhängigkeiten üblicherweise transitiv sind.

Was lange währt…

Sind alle rechtlichen Aspekte geklärt, ist das Projekt endlich bereit für den letzten Schritt. Das erste offizielle Release eines Eclipse Projektes hat eine ganz besondere Bedeutung, da es das Ende der Inkubationsphase darstellt. Aber auch für ein solches Release ist etwas Bürokratie nötig. Möchte ein Projekt die erste Version veröffentlichen, so findet ein so genanntes „Release Review“ statt. Der wichtigste Bestandteil des Reviews ist die „Review Documentation“, welche durch die Committer erstellt wird und alle wesentlichen Aspekte des geplanten Releases zusammenfast. Vom Prinzip her ist die Review Documentation den klassischen Release Notes sehr ähnlich. Ist das erste Release Review erfolgreich, kann das Projekt die entsprechenden Artefakte veröffentlichen, beispielsweise indem sie ins Maven Central Repository übertragen werden.

Kennt man den Ablauf der Inkubationsphase für neue Eclipse-Projekte, ist vermutlich auch klar, warum der Prozess bei mehr als 40 Projekten mit insgesamt über 10 Millionen Quellcodezeilen doch recht lange dauern kann. Auch wenn einige Phasen sehr bürokratisch sind, so sind diese doch zwingend notwendig, um Jakarta EE auf eine solide Basis zu stellen und somit auch Rechtssicherheit für Endnutzer zu schaffen.

Und wie ist der Stand heute? Inzwischen haben alle Projekte einen Großteil des Inkubationsprozesses geschafft und stehen kurz vor dem ersten Release. Der aktuelle Fokus liegt nun auf der Integration aller relevanten Komponenten in Eclipse Glassfish. Mit dem Release von Eclipse Glassfish wäre der Transfer zur Eclipse Foundation dann abgeschlossen.

Geschrieben von
Christian Kaltepoth
Christian Kaltepoth
Christian Kaltepoth arbeitet als Senior Developer bei ingenit GmbH & Co. KG in Dortmund. Sein Schwerpunkt ist die Entwicklung von webbasierten Unternehmensanwendungen auf Basis von Java-EE-Technologien. Darüber hinaus ist er in mehreren Open-Source-Projekten wie Apache DeltaSpike, Rewrite, PrettyFaces und Togglz aktiv. Er ist Mitglied der JSR 371 Expert Group und ein regelmäßiger Sprecher auf Konferenzen.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: