Ant macht Versionisierung von Java Jars einfach und betriebssicher

Kurz erklärt: Die Java-Source-Datei des Beispielprogramms MyApp.java (Listing A). Innerhalb dieser Class-Datei sind ein paar statische Variablen und Methoden zu sehen. Die erste Variable mit Namen „RELEASE“ hat den Wert „@RELEASE@“. Dieser Platzhalter wird später von Ant ersetzt. Für’s erste soll der Wert „@RELEASE@“ bleiben.

Die erste der zwei statischen Methoden, „getVersionString()“, verknüpft einfach die Werte von weiteren statischen Variablen und fügt dann – wenn gewünscht – den Wert der Variablen „RELEASE“ an. Dies passiert nur, wenn die Variable „RELEASE“ nicht gleich „@RELEASE@“ ist. Wenn aber der Wert von „RELEASE“ vor dem Kompilieren geändert wurde, wird der geänderte Wert zum zurückgegebenen Versionsstring angefügt.

Zu beachten ist, dass der Wert der Variable „RELEASE“ in zwei Strings aufgeteilt wird, die dann durch den Compile-Vorgang wieder zusammengesetzt werden. So wird Ant davon abgehalten, diesen Platzhalter ebenfalls zu ersetzten.

In der Datei „build.xml“ (Listing B) werden einige nicht offensichtliche Techniken verwendet. Ziel ist es dem Entwickler das Bereitstellen von Versions-Informationen für jeden Compile-Vorgang abzunehmen. Die meisten Kompilierungen fließen gar nicht in eine neue Version ein, so dass Entwickler – müssten sie für jede Test-Kompilierung eine neue Versionsnummer angeben – dies sicher bald durch ein Script mit einer festen Versionsnummer umgehen würden. Dies würde den gesamten Prozeß zunichte machen.

Um also eine vernünftige Versionierung zu bekommen, müssen die „Targets“ für die Erzeugung der Klassen und aller JARs aufgeteilt werden. Das Target mit dem Namen „classes“ setzt ursprünglich die Eigenschaft (Property) „srcdir“ auf das vorher definierte Sources-Verzeichnis. Somit werden, wenn das „classes“-Target direkt ausgeführt wird, die Java Sourcen im angegebenen Verzeichnis kompiliert.

Jedoch ist es nicht erwünscht, dass die durch das Kompilieren aus den Source-Dateien erzeugten „.class“-Dateien zusammen mit den „.java“-Dateien im Source-Verzeichnis stehen. Stattdessen wird nun eine Kopie der Source-Dateien erzeugt – und dabei wird das Ersetzen der Tokens vollzogen. Erstellen und spezifizieren des alternativen Source-Verzeichnisses erfolgt im „pre-jar“-Target. Dieses Target setzt das „srcdir“-Property nicht auf den Wert des Source-Verzeichnisses (wie es das „classes“-Target macht), sondern auf ein Unterverzeichnis des neu erzeugten „jar“-Verzeichnisses.

Das „pre-jar“-Target kopiert dann den Source-Code rekursiv in ein Verzeichnis innerhalb des „jar“-Verzeichnisses. Während dieses Kopierens wird ein „filterset“ dazu verwendet, alle vorkommenden „@RELEASE@“-Zeichenketten durch das gesetzte „release“-Property zu ersetzen. Das „classes“-Target versucht den Wert von „srcdir“ neu zu setzen, nachdem dieses bereits vom „pre-jar“-Target auf das neue Source-Verzeichnis gesetzt wurde. Allerdings lassen die Ant-Regeln es nicht zu, den Wert eines einmal gesetzten Property zu überschreiben.

Das „pre-jar“-Target verarbeit das Filtern der „@TEXT@“-Platzhalter, allerdings stellt es nicht sicher, dass das „release“-Property – dessen Wert für den „@RELEASE@“-Platzalter eingesetzt wird – einen Wert zugewiesen bekommen hat. Diese Prüfung wird vom „ensure-release“-Target vorgenommen. Ist „release“ nicht gesetzt, wird mit einer Fehlermeldung abgebrochen, die erklärt, wie der „release“-Wert im Ant-Aufruf gesetzt werden muss.

Was am Ende dabei herauskommt

Der Aufruf der „pre-jar“- und „ensure-release“-Targets wird durch die angegebenen Abhängigkeiten (depends) im „jar“-Target automatisiert. Das „jar“-Target stellt also sicher, dass vor der Abarbeitung seiner Aufgaben sowohl das „pre-jar“- als auch das „classes“-Target durchlaufen wurden. Das „pre-jar“-Target wiederum ruft das „ensure-release“-Target auf, um zu überprüfen, ob ein „release“-Wert gesetzt wurde. Das Ergebnis ist ein Build-System, das einerseits durch das „classes“-Target für alltägliches Kompilieren und Testen, andererseits durch Verwendung des „jar“-Targets für die Erstellung eines JARs mit den nötigen Versionsnummern geeignet ist.