Maven-Release-Plug-in: Fehlerteufel ade!

Ablauf anhand eines Beispiels

Um den gesamten Ablauf durchzugehen, erstellen wir zunächst ein kleines Maven-Projekt. In Eclipse gehen wir dazu auf FILE | NEW | PROJECT | MAVEN PROJECT und vergeben eine Group Id (com.example.test) und eine Artifact Id (maven.release.plugin.test). Als Version nehmen wir 0.0.1-SNAPSHOT (Abb. 1).

Abb. 1: Anlegen eines neuen Maven-Projekts

Als Nächstes sollte das neu erstellte Maven-Projekt initial ins SVN eingecheckt werden. Anschließend müssen die pom.xml geöffnet, das Maven-Release-Plug-in, die SCM Connection mit dem Pfad zum Sourcecode Repository und das Distribution Management wie weiter oben beschrieben referenziert werden. Die vollständige pom.xml ist in Abbildung 2 dargestellt.

Abb. 2: Vollständig konfigurierte pom.xml

Nach dem erneuten Einchecken der editierten pom.xml ist das Projekt soweit konfiguriert, dass es releast werden kann. Natürlich hat unser Projekt noch keinerlei Funktionalität, da es weder Klassen noch Unit Tests beinhaltet. Am grundsätzlichen Vorgang des Releaseablaufs ändert sich jedoch nichts. Ein bewährtes Vorgehen, um ein Release durchzuführen, ist, das Projekt an einer Stelle außerhalb des Eclipse Workspace neu auszuchecken und von dort das Release zu starten. So kann im Fall, dass das Release fehlschlägt, das Projekt einfach gelöscht und nochmals neu ausgecheckt werden, ohne dass der Eclipse Workspace durch Altlasten verunreinigt wird. Starten wir also unser Kommandozeilentool (z. B. Cygwin) und navigieren zu einer geeigneten Stelle, um den Checkout zu initiieren:

$ cd /cygdrive/c/local/builds/
$ svn co https://myserver/svn/maven-release-plugin-test maven-release-plugin-test
$ cd maven-release-plugin-test

Jetzt können wir die erste Phase, das Preparing, einleiten, indem wir in der Konsole $ mvn release:prepare eingeben und mit Enter bestätigen. Zunächst werden wir nach der gewünschten Versionsnummer gefragt:

What is the release version for „maven.release.plugin.test“? (com.example:maven.release.plugin.test) 0.0.1: :

Dabei wird ein Vorschlag für die zu verwendende Versionsnummer (0.0.1) gemacht. Jetzt kann von Hand eine gewünschte Nummer eingegeben oder der Vorschlag durch Drücken der Enter-Taste übernommen werden, was in den meisten Fällen zu bevorzugen sein sollte. Als Nächstes kommt die Frage nach dem gewünschten Namen des anzulegenden tag-Verzeichnisses:

What is SCM release tag or label for „maven.release.plugin.test“? (com.example:maven.release.plugin.test) maven.release.plugin.test-0.0.1: :

Wie bei der ersten Frage kann auch hier wieder mit Enter der Vorschlag (maven.release.plugin.test-0.0.1) übernommen oder ein eigener Tag-Name vergeben werden. Anschließend muss noch die gewünschte Versionsnummer für die weitergehende Entwicklung (d. h. die nächste -SNAPSHOT-Version) definiert werden:

What is the new development version for „maven.release.plugin.test“? (com.example:maven.release.plugin.test) 0.0.2-SNAPSHOT: :

Nachdem diese drei Fragen beantwortet sind, beginnt das Plug-in damit, die einzelnen Aufgaben der ersten Phase wie weiter oben beschrieben abzuarbeiten, und nach ein paar Sekunden sollte „Build Successful“ ausgegeben werden. Herzlichen Glückwunsch, damit ist die erste Phase erfolgreich abgeschlossen worden! Für den Fall, dass die Preparation-Phase nicht erfolgreich sein sollte („Build Failure“), sollte zwingend $ mvn release:rollback ausgeführt werden, bevor mit der Fehlersuche begonnen wird. Ein Rollback stellt den Ursprungszustand der pom.xml wieder her (in unserem Beispiel wäre die Versionsnummer wieder 0.0.1.-SNAPSHOT) und löscht temporär angelegte Dateien. Zusätzlich sollte überprüft werden, ob im Sourcecode Repository nicht bereits das tag erzeugt wurde. Falls ja, sollte dieses unbedingt manuell gelöscht werden. Wenn die erste Phase erfolgreich abgeschlossen wurde, können wir direkt die zweite Phase einleiten, indem wir $ mvn release:perform eingeben. Jetzt wird das Artefakt gebaut (falls wir Unit Tests hätten, würden diese auch nochmals ausgeführt) und anschließend auf das Maven Repository (hier: Nexus) deployt. Da wir die Standardeinstellungen des Plug-ins verwenden, werden die Sourcen und die JavaDocs ebenfalls deployt. Nach der Meldung „Build Successful“ kann das Artefakt auf dem Repository abgerufen werden (Abb. 3).

Abb. 3: Release auf Repository Manager

Somit haben wir einen vollständigen Releasezyklus durchlaufen. Dabei wurden die in der Einleitung genannten Fragen allesamt beantwortet: Die Versionsnummer des Artefakts wurde fixiert, die pom.xml wurde aktualisiert, es wurde ein tag im Repository angelegt, und das Artefakt samt Sourcen und JavaDoc wurde sauber auf dem Nexus deployt. Nach einem Update der lokalen Projekt-Sourcen wird die Versionsnummer in unserem Beispiel auf 0.0.2-SNAPSHOT stehen. Somit kann mit der Entwicklung des Projektes unmittelbar fortgefahren werden – bis zum nächsten Release, bei dem das ganze Spiel wieder von vorne beginnt.

Fazit

Das Maven-Release-Plug-in hat uns sehr dabei geholfen, ein sauberes und reproduzierbares Release zu erstellen, da es uns von Anfang bis Ende durch einen kontrollierten und standardisierten Prozess geleitet hat. Das Vergeben von Versionsnummern und das Pflegen der pom.xml ist vollständig automatisiert, das Taggen sowie das Deployment des Artefakts auf das Repository werden vom Plug-in selbständig durchgeführt. Durch diese Entlastung des Entwicklers wird der gesamte Releasezyklus weniger komplex, das heißt der Entwickler hat mehr Freiraum, um sich den eigentlichen Problemen zu widmen. Besonders wertvoll wird diese Unterstützung bei Multi-Module-Projekten, bei denen das manuelle Releasen mit jedem zusätzlichen Modul umständlicher und aufwändiger wird – und mit zunehmender Komplexität steigt natürlich auch die Möglichkeit, Fehler zu machen. Aufgrund der genannten Sachverhalte und der einfachen Integration und Konfiguration kann ich jedem Java-Maven-Entwickler nur ans Herz legen, das Plug-in regelmäßig einzusetzen! Wenn sich die Person, die das Release durchführt, zusätzlich committet, einen kurzen Changelog im Wiki oder Ähnliches zu erstellen, steht einem regelmäßigen Release durch die einfache und komfortable Handhabung des Maven-Release-Plug-ins nichts mehr im Wege.

Marcel Hallmann beendete sein Studium der Informationstechnologie (BA) im Jahre 2008 und arbeitet seither bei der SIX Group AG in Zürich als Application Engineer. Dort sind seine Hauptaufgaben die Entwicklung und Wartung von Webapplikationen, momentan in erster Linie mit Vaadin. Dabei betreut er die Datenzugriffsschicht, den Serviceteil und den GUI Layer.
Kommentare

Schreibe einen Kommentar

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