Migration incoming...

Projekt Skara & JEP 357: Java Repositorys bald auf Git

Dominik Mohilo

© Shutterstock / Maquette.pro

Projekt Skara wurde vor wenigen Monaten ins Leben gerufen, um die möglichen Alternativen für Mercurial als Versionskontrollsystem zu evaluieren. Nun scheint das Projekt sich langsam aber sicher einem Ende zuzuneigen, denn JEP 357 und damit der Umzug der Java Repositorys nach Git wurde von höchster Stelle zur Diskussion gestellt.

Es war bereits von Anfang an klar, dass es sich bei Projekt Skara nicht um die Frage drehen würde, ob die Java Repositorys bald auf ein neues Versionskontrollsystem (VCS) umziehen würden. Vielmehr wurde der Fokus darauf gelegt, welches VCS denn das richtige sein könnte. Die Antwort war eigentlich ebenfalls schon relativ bald klar: Git. Nun war lediglich noch festzustellen, ob dieses Projekt wirklich durchführbar sei und in welcher Form.

Für große Projekte wie das JDK ist die Versionskontrolle, also das Source-Code-Management (auch als SCM bekannt), ein wichtiger Teil der Infrastrukturverwaltung und des Workflow-Prozesses. Das traditionell für das JDK und Satelliten-Projekte eingesetzte Mercurial ist ein wenig in die Jahre gekommen. Auch die Art und Weise, Code Reviews durchzuführen, aktuell noch via Mailing-Listen, ist nicht wirklich modern. Git bietet hier adäquatere Alternativen.

Die Früchte des Projekt Skara: JEP 357 & JEP ???

Nein, der Zwischentitel ist kein Tippfehler – es wurde auch nicht vergessen, eine Nummer nachzutragen. Die Erklärung folgt auf dem Fuße: JEP 357 (Migrate from Mercurial to Git) ist das erste JEP, das auf den Diskussionen und Evaluierungen aus Projekt Skara basiert, aber es wird mindestens noch ein weiteres JEP geben müssen, wie in den „Non-Goals“ des neuesten JEPs von Joe Darcy und Erik Duveblad bereits angekündigt wurde.

JEP 357 hat prinzipiell erstmal nur das Ziel, die Source-Code-Repositorys des OpenJDK von Mercurial auf Git zu migrieren. Damit einher geht eine umfangreiche Sicherungsaktion, denn natürlich soll die gesamte Historie aller Java-Versionen (inklusive Tags) erhalten bleiben.

In Sachen Tools wurde, wie wir bereits sehen konnten, ganze Arbeit geleistet: Etliche CLI- und Import/Export-Tools sind bereits vorhanden und stehen quelloffen zur Verfügung. Für die Tools jcheck, webrev und defpath gibt es ebenfalls bereits rückwärtskompatible Prototypen und das neue Tool git-translate existiert ebenfalls als Prototyp.

Wofür JEP 357 nicht steht, das machen die Autoren des Proposals klar, ist die Definition ob und wenn ja auf welchem externen Hoster die JDK Repositorys künftig liegen sollten. Ob also Java in absehbarer Zeit als offenes Projekt auf GitHub liegen wird, wird an anderer Stelle in einem anderen JEP diskutiert und herausgefunden werden müssen. Ein Kritikpunkt, der auch von Roman Kennke in einer Diskussion auf der OpenJDK-Mailing-Liste kommentiert wurde:

While I somehow can understand the motivation to break this out, it leaves me wondering where will the new repos be hosted after all. Or is that another unnamed JEP intended to become a prerequisite for JEP 357? This seems impossible too.

Demnach sei es schwierig, die Frage nach dem Hosting von der Migration gänzlich zu trennen. Einen Schritt weiter geht Aleksey Shipilev in seinem Beitrag. Darin bemängelt er, dass in JEP 357 lediglich die Vorteile und nicht die Nachteile von einer Migration von Mercurial zu Git besprochen werden.

Weitere Informationen zu Projekt Skara gibt es auf JAXenter, alles zum aktuellen JEP im entsprechenden Proposal. Diskutiert wird der Vorschlag auf der Malining-Liste des OpenJDKs.

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

1 Kommentar auf "Projekt Skara & JEP 357: Java Repositorys bald auf Git"

avatar
4000
  Subscribe  
Benachrichtige mich zu:
trackback

[…] Projekt Skara & JEP 357: Java Repositorys bald auf Git – (Lesedauer: ca. 3 Minuten) […]