Suche
Adieu, JCP!

Eclipse Foundation Specification Process: Erster Entwurf für den neuen Jakarta-EE-Spezifikationsprozess veröffentlicht

Dominik Mohilo

© Shutterstock / Rawpixel.com

Seit etwas mehr als einem Jahr ist klar, dass die Java Enterprise Edition an die Eclipse Foundation geht, der Prozess ist im vollen Gange und nimmt immer konkretere Formen an. Jakarta EE, wie Java EE nun heißt, wird mit dem Umzug zur Eclipse Foundation auch den alten Spezifikationsprozess (JCP) erneuern – der erste Entwurf für den neuen Prozess liegt der Community nun vor.

Die Jakarta EE Community wartete auf diese Neuigkeit schon seit einer Weile: Der erste Vorschlag für den Jakarta EE Specification Process ist endlich veröffentlicht worden. Die Mitglieder der Jakarta-EE-Gemeinde sind noch hochoffiziell dazu aufgefordert, sich über etwaige Ergänzungswünsche Gedanken zu machen und Feedback zum Prozessvorschlag zu geben.

Eclipse Foundation Specification Process: JCP wird zu EFSP

Einen passenden Namen für das Ganze hat die Eclipse Foundation bereits vorgegeben. So soll der neue Prozess „Eclipse Foundation Specification Process“ (kurz: EFSP) heißen. Was auf den ersten Blick ein wenig eitel erscheint, hat durchaus System: Dem EFSP liegt der Eclipse Development Process (EDP) zugrunde, der durch den neuen Prozess genutzt und von diesem erweitert werden soll. Zur Erinnerung: im EDP sind wichtige Statuten festgelegt, wie etwa die Open Source Rules of Engagement und organisatorische Vorgaben zur Arbeit unter dem Dach der Eclipse Foundation.

Wie Mike Milinkovich, Exectuive Director der Eclipse Foundation, auf seinem Blog schreibt, gab es gute Gründe den etwas angestaubten Java Community Process (JCP) für das neue Projekt Jakarta EE abzuschaffen und durch einen neuen zu ersetzen. Unter anderem soll der neue Prozess leichtgewichtiger und der Entwicklung im Open-Source-Umfeld möglichst nahe sein. Dass sich die Eclipse Foundation dabei auf Statuten aus dem bestehenden Eclipse Development Process stützen will, erscheint da nur logisch.

Ein weiterer wichtiger Punkt des neuen EFSP ist die sogenannte Code-First-Entwicklung. Damit ist gemeint, dass – wie im Open-Source-Umfeld üblich – Experimente möglich bleiben sollen, bevor darauf basierend später Spezifikationen erstellt werden. Diese Art des Zusammenspiels zwischen festen Spezifikationen und Innovation bzw. Experimenten wird von vielen Jakarta-EE-Experten ausdrücklich gefordert, wie sie in unserer Reihe „Jakarta EE im Klartext“ deutlich machen.

Natürlich gelten in Bezug auf die neuen Spezifikationen der höchste Qualitätsanspruch und das Gebot der Rechtssicherheit. Um beides zu gewährleisten gibt es zwei grundlegende Abweichungen des EFSP vom EDP: Zum einen muss das Specification Committee den Veröffentlichungen der Spezifikationsprojekte zustimmen (zusätzlich zum Project Management Committee). Zum anderen wird der Prozess eine neue Mitgliedergruppe umfassen, die sogenannten Participants. Participants sind Committer innerhalb eines Spezifikationsprojektes, die ein Unternehmen vertreten.

API Summit 2018
Christian Schwendtner

GraphQL – A query language for your API

mit Christian Schwendtner (PROGRAMMIERFABRIK)

Der neue Prozess

Um eine neue Spezifikation (oder eine neue Version für eine Spezifikation) auf den Weg zu bringen, muss ein Projekt den formalen Release-Zyklus durchlaufen. Dessen Einhaltung und Fortschritt wird unter anderem vom PMC und vom oben erwähnten Specification Committee überwacht. Wie bei Eclipse-Projekten üblich, werden neue Spezifikationen nach dem EDP erstellt. Steht nun ein neuer Release-Zyklus an, geht das Projektteam wie folgt vor:

Zunächst wird ein Release Plan erstellt, der vom Specification Committee mit einer eindeutigen Mehrheit abgesegnet sein muss. Das Projektteam arbeitet dann an der Spezifikation (es muss mindestens ein Milestone Release zwischendurch einem Progress Review unterzogen werden). Ist die Spezifikation bzw. die neue Version fertig, wird sie als neue Specifiation Version veröffentlicht. Bevor sie allerdings offiziell und final in Jakarta EE einfließen kann, muss sie ratifiziert werden. Dies geschieht über ein erneutes Release Review der finalen Version der Spezifikation.

Weitere Informationen zum neuen Eclipse Foundation Specification Process finden sich auf dem Blog von Mike Milinkovich, der Entwurf wird aktuell als Google Doc von der Community in Augenschein genommen. Feedback sollte entweder als Kommentar direkt in dem Dokument eingefügt werden, lieber sähe man das Feedback allerdings auf der entsprechenden Mailing-Liste.

Mehr zum Thema Jakarta EE:

Unsere Interview-Reihe: Jakarta EE im Klartext

In unserer Interview-Reihe sprechen Experten der Enterprise-Java-Szene Klartext darüber, was sich im Laufe der letzten Wochen und Monate verändert hat und in welche Richtung sich Jakarta EE entwickelt. Zentrales Thema ist dabei unter anderem, wie Jakarta EE zum neuen Zuhause für Cloud-native Java werden soll.

Ab geht die Reise ins Jakarta-EE-Universum mit unseren Experten!

Geschrieben von
Dominik Mohilo
Dominik Mohilo
Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: