Versionsnamen mit Maven: Erzeugen des Versionsnamens

Im Folgenden wird der Begriff „Versionsname“ verwendet, um die mit weiteren Informationen angereicherte Versionsnummer zu bezeichnen.
Der generelle Mechanismus, um den Versionsnamen in die Anwendung zu schreiben, sieht wie folgt aus: Es wird das Maven Property versionName erzeugt, das mittels Resource Filtering in Dateien der Anwendung geschrieben wird. In diesem Artikel wird dies für eine Properties-Datei, eine HTML-Datei und die Manifest-Datei gezeigt.
Der einfachste Versionsname besteht aus der Maven Version, die im Tag spezifiziert wird:

Zunächst muss der Versionsname mittels Maven Resource Filtering in Dateien geschrieben werden. Von dort kann er von der Anwendung gelesen werden. Ein universell einsetzbares Vorgehen ist es, den Versionsnamen in eine Properties-Datei zu schreiben. Beispielsweise legt man eine Datei src/main/resources/app.properties an, die das oben definierte Property versionName enthält:

Der Platzhalter wird während des Maven Builds wie folgt ersetzt:

Die Properties-Datei, die während des Builds im Maven target Verzeichnis abgelegt wird, sieht dann wie folgt aus:

In Webanwendungen kann man es sich noch einfacher machen. Man schreibt den Versionsnamen direkt in eine HTML-Datei, die an den Client ausgeliefert wird. Beispielsweise legt man eine Datei src/main/webapp/index.html an, die das oben definierte Property versionName enthält:

Der Platzhalter wird während des Maven Builds mittels Resource Filtering des maven-war-plugins wie folgt ersetzt:

Die HTML-Datei, die während des Builds im Maven target Verzeichnis abgelgt wird, sieht dann wie folgt aus:

Wenn man eine JAR-Datei ausliefert hat man eine weitere Möglichkeit: Das Schreiben des Versionsnamens in die Manifest-Datei. Dies hat den Vorteil, dass keine weitere Properties-Datei angelegt werden muss. Dies kann entweder mittels maven-jar-plugin oder maven-assembly-plugin erfolgen, wobei der Tag jeweils gleich aussieht. Das folgende Beispiel zeigt, dies anhand des maven-assembly-plugins:

Die Manifest-Datei, die während des Builds innerhalb der JAR-Datei unter META-INF/MANIFEST.MF erstellt wird, sieht dann beispielsweise wie folgt aus:

Im Folgenden wird gezeigt, wie sich der Versiosname sukzessive um weitere Informationen erweitern lässt. Ein Zeitstempel kann mit Maven Bordmitteln hinzugefügt werden. Dazu definiert man zunächst das maven.build.timestamp.format Property und verwendet dann das maven.build.timestamp Property im versionName Property:

Möchte man zusätzliche Informationen aus dem Source Code Management (SCM) anzeigen, bietet sich die Verwendung des buildnumber-maven-plugin an. Es arbeitet mit den SCMs subversion, git, mercurial und perforce. Nach der Ausführung des Goals create (standardmäßig in der initialize Phase des Maven Build Zyklus) stehen die Properties buildnumber und scmBranch zur Verfügung. Das folgende Beispiel zeigt wie dieses für ein Multi-Module-Projekt unter Verwendung von Git aussehen kann:

Im Versionsnamen kann man dann die Properties, die durch das Plugin bereitgestellt werden, verwenden:

Bei Verwendung eines Continuous Ingetration (CI) Tools wie Jenkins kann zudem die Build-Nummer in den Versionsnamen einfließen. Dadurch können dann lokale Entwickler-Builds von CI-Builds unterschieden werden. Um in Maven den CI-Build von anderen zu unterscheiden, bietet sich die Verwendung eines Maven Profiles an. Jenkins injiziert die aktuelle Build-Nummer des Jobs in die Umgebungsvariable BUILD_NUMBER. Diese kann sowohl als zur Aktivierung des Profils, als auch in der Build-Nummer selbst verwendet werden. Das folgende Snippet führt dazu, dass auf Jenkins ohne weitere Konfiguration zusätzlich die Build-Nummer in den Versionsnamen aufgenommen wird:

Mit den oben gezeigten Erweiterungen ist der Versionsname nun sehr lang und enthält Informationen, die primär für Entwickler von Interesse sind. Tatsächlich ist die Versionsnummer einer Anwendung für sich in Produktion schon ein eindeutiges Merkmal. Insofern sind diese zusätzlichen Informationen beim Release nicht unbedingt notwendig. Wenn man also zwischen Entwicklungs- und Release-Versionen unterscheiden möchte, lässt sich dies ebenfalls mittels Maven Profiles realisieren. Das maven-release-plugin setzt beispielsweise das Attribut performRelease, während das Release erstellt wird (Goal release:perform). Dieses bietet sich an dieser Stelle als Best Practice zur Aktivierung des Profils an: