Der erste Artikel in dieser Serie – „Versionsnamen mit Maven: Erzeugen des Versionsnamens“ zeigt, wie mit Hilfe von Maven während des Builds eine Versionsnummer, angereichert mit weiteren Informationen in eine Manifest-, Properties- oder HTML-Datei geschrieben wird. Darauf aufbauend beschreibt dieser Artikel, wie diese innerhalb der Anwendung ausgelesen wird. Dies ist in vielen Fällen hilfreich: Man sieht sofort, welche Version auf welcher Stage deployt ist, die Versionsangabe kann Missverständnisse in Fehlerberichten vermeiden, etc.

Im Folgenden wird der Begriff „Versionsname“ verwendet, um diese mit weiteren Informationen (wie Build-Nummer, Zeitstempel, Branch und Commit ID) angereicherte Versionsnummer zu bezeichnen.

Dieser Artikel zeigt zunächst, wie das programmatische Auslesen des Versionsnamens aus Properties- und Manifest-Dateien mit JDK-Bordmitteln grundlegend funktioniert. Um dies nicht in jeder Anwendung erneut implementieren zu müssen, wurde dies in eine kleine, wiederverwendbare Bibliothek ausgelagert (siehe versionName bei GitHub). Anhand dieser werden im weiteren Verlauf ausführbare Beispiele (Client-Anwendung und Webanwendung, siehe versionName/examples bei GitHub) gezeigt.

Ein programmatischer Zugriff auf den Versionsnamen in der HTML-Datei ist nicht notwendig, da dieser während des Builds direkt in die Datei geschrieben wird und diese direkt auf dem Client angezeigt wird.

Versionsnamen aus einer Properties-Datei auslesen

Die wesentliche Logik für das Auslesen des Versionsnamens aus einer Properties-Datei sieht wie folgt aus:

Auf Exception-Handling, Schließen von Ressourcen und Prüfungen auf null wurde in diesem Snippet aus Gründen der Übersicht verzichtet. In der Bibliothek versionName wird dies in der Methode VersionNames.getVersionNameFromProperties() realisiert. Diese gibt defensiv immer eine Instanz vom Typ String (niemals null) zurück. Im Fehlerfall wird ein leerer String zurückgegeben. Fehlermeldungen werden mittels SLF4J geloggt.

Versionsnamen aus dem Manifest auslesen

Analog zum Auslesen der Versionsnamen aus einer Properties-Datei, sieht das Auslesen aus der Manifest-Datei wie folgt aus:

Auch in diesem Snippet wurde auf Exception-Handling, etc. aus Gründen der Übersicht verzichtet. In der Bibliothek versionName wird dies in der Methode VersionNames.getVersionNameFromManifest() realisiert. Auch diese gibt defensiv immer eine Instanz vom Typ String (niemals null) zurück und loggt Fehlermeldungen mittels SLF4J.

Verwendung der Bibliothek versionName

Um den Versionsnamen mittels der Bibliothek versionName auslesen zu können, muss diese im Classpath vorhanden sein. Derzeit ist versionName noch nicht im MavenCentral Repository verfügbar. Man kann sie jedoch mittels des JitPack-Repositories, das auf dem Code bei GitHub basiert, verwenden. Dieses spezifiziert man in der pom.xml wie folgt:

Damit kann dann die folgende Dependency aufgelöst werden:

Alternativ kann man die Klasse VersionNames und die zugehörigen Unit-Tests in das jeweilige Projekt kopieren.

Beispiel Client-Anwendung

Das einfachste ausführbare Beispiel ist eine Client-Anwendung, die in einer JAR-Datei gepackt wird. In dieser kann man den Versionsnamen wie folgt aus der Manifest-Datei auslesen (siehe auch App.java):

Kompiliert man diese Klasse mit Abhängigkeiten in eine JAR-Datei (siehe Beispiel „jar“), kann diese so ausgeführt werden:

Dies führt beispielsweise zu folgender Ausgabe:

Beispiel Webanwendung

In Webanwendungen bietet es sich an, den Versionsnamen direkt in eine HTML-Datei zu schreiben und im Client anzuzeigen. Damit ist kein programmatischer Zugriff nötig.

Soll der Versionsname auf dem Server verfügbar sein, bietet sich die Verwendung einer Properties-Datei an. Aus dieser kann man den Versionsnamen beispielsweise als JAX-RS-Ressource zur Verfügung stellen (siehe auch VersionResource.java):

Das Beispiel „war“ zeigt eine Webanwendung (die in eine WAR-Datei gepackt wird), die die VersionResource und die zugehörige JAX-RS Application Klasse (siehe RestApplication.java) enthält. Außerdem wird durch den Build der Versionsname in eine HTML- und Properties-Datei geschrieben.

Kompiliert man dieses mit Abhängigkeiten in eine JAR-Datei (siehe Beispiel „server“), die die WAR-Datei auf einem embedded Servlet Container (z.B. Jetty) bereitstellt, kann diese so ausgeführt werden:

Nach erfolgreichem Ausführen dieses Befehls gibt sowohl der Aufruf der HTML-Datei unter der URL localhost als auch der Aufruf der JAX-RS-Ressource unter der URL localhost/api/version beispielsweise Folgendes zurück:

Fazit

Diese Artikelserie zeigt im ersten Teil
• wie man den Versionsnamen mit Maven in verschiedene Datei-Typen (Manifest, Properties, HTML) schreibt,
• verschiedene Optionen, mit denen der Versionsname erweitert werden kann (Build-Nummer, Zeitstempel, Branch und Commit ID) ,
und in diesem zweiten Teil
• den generellen Mechanismus zum Auslesen des Versionsnamen aus diesen Dateitypen mit JDK-Bordmitteln,
• die Verwendung der Bibliothek versionName, die eine komfortable Wiederverwendung dieses Mechanismus ermöglicht und
• ausführbare Beispiele (Client- und Webanwendung), die all diese Inhalte integrieren.

Kommentare

Keine Kommentare

Ähnliche Beiträge

Statische Codeanalyse mit SonarQube

Autor
  • Josha von Gizycki
Publiziert

Manchmal fragen sich Entwickler: „Was mache ich hier eigentlich?“ Das hat dann nichts mit einer plötzlichen Sinneskrise oder dem Zusammenbruch der persönlichen Weltanschauung zu tun. Vielmehr wacht der innere Softwarearchitekt auf und verlangt nach einer Darstellung des Großen Ganzen.

Eine Groovy-DSL zum Erzeugen von Testdaten über JPA

Autor
  • Daniel Behrwind
Publiziert

Beim automatisierten, integrativen Testen von Software, die mit einem komplexen JPA-Datenmodell arbeitet, steht man unweigerlich früher oder später vor der Frage, wie sich semantisch sinnvolle Testdaten ohne großen Aufwand erzeugen lassen. Dieser Artikel zeigt, wie man mit Groovy eine Domain Specific Language (DSL) definieren kann, die es erlaubt, Testdaten leicht lesbar, modular und getrennt vom eigentlichen Test-Code zu definieren.

SLF4J und Logback in Android

Autor
  • Johannes Schnatterer
Publiziert

Wenn man als Java-Entwickler in die Android-Entwicklung einsteigt, ist zunächst vieles aus Java bekannt. Einige Aspekte sind aber auch anders gelöst. So zum Beispiel das Thema Logging. Hier bringt Android seine eigene API mit, die ohne weitere Konfiguration bequem verwendet werden kann. Bei fortgeschrittenen Herausforderungen zeigt dieser Ansatz jedoch seine Grenzen. Hier kann auf vorhandenes Wissen und Bibliotheken aus der Java-Welt zurückgegriffen werden.

Mutation Testing mit Pitest

Autor
  • Philipp Czora
Publiziert

Codequalität und -korrektheit lassen sich unter anderem mit Hilfe von Unit-Tests sicherstellen. Aber nicht jeder Unit-Test ist sinnvoll und häufig schaffen es Bugs von Unit-Tests unerkannt zu bleiben. Wie lässt sich die Testqualität erhöhen, um Programmierfehler zuverlässiger und früher zu erkennen?