Möchte man die Applikation nun fertigstellen und anderen zur Verfügung stellen – oder früher im Rahmen von Enduser-Tests – so kommt es bei großen Projekten unweigerlich zu Problemen.

Im Folgenden beschäftige ich mit den Problemen:

1. Wie exportiere ich ein Projekt mit vielen externen Jars einfach und sicher in ein lauffähiges Jar?
2. Wie stelle ich sicher, das sowohl in der Entwicklungsumgebung als auch in der Jar alle Bilder o.ä. Ressourcen wiedergefunden werden?
3. Wie nutze ich einen eigenen Buildprozess und
4. Wie kann ich im Buildprozess Zusatzinformationen wie die aktuelle SVN-Revision oder das Build-Datum verwerten?

Problem 1: Viele externe Jars

Eclipse bietet im Exportwizard die Möglichkeit, eine Jar-Datei zu erstellen. Dabei wird das aktuelle Projekt ohne die verlinkten Jar-Dateien erstellt. Unschön, wenn man die Applikation als ganzes anbieten will. So eine Art Out-of-the-Box.

Seit Eclipse 3.4 bietet der Exportwizard eine Neuerung, die so genannte Runnable Jar. Dabei werden neben den eigenen Class-Dateien alle verlinkten Jars (sind ja in Wirklichkeit Zip-Dateien) extrahiert und alles, wirklich alles, in eine Jar geschmissen. Das funktioniert in einigen Fällen, ist aber erstens unschön, kann zweitens zu Problemen bei Namenskonflikten führen (bsp. Resourcenodner) und ist drittens u.U. nicht mit der Lizenz vereinbar. Auch nicht so ganz schön.

Das zuletzt angesprochene neue Feature ist eine Art “Light-Version” des Fat Jar Eclipse-Plugin. Das eigentliche Plugin selber hingehen bietet mehr: Das angegebene Projekt wird in ein Jar zusammengefügt (vgl. Option 1). Dazu kommen alle externen Jars – und entgegen der zweiten Option so wie sie sind. Das ganze wird in eine große Jar (quasi ein Wrapper) gepackt und mit einem kleinen “Bootloader” versehen. Perfekt!

Problem 2: Lokale Ressourcen wie Bilder o.ä.

Im lokalen Projekt funktioniert natürlich immer der Zugriff auf alle Ressourcen. Möchte man später jedoch ein Jar anbieten, muss man sich an einige Spielregeln halten. Erstens müssen sich die Ressourcen im (lokalen) Classpath befinden oder diesem bekannt gemacht werden. Zweitens können die Ressourcen selber nicht normal via File-Konstruktor geöffnet werden, sondern müssen über den ClassLoader geladen werden. In der Regel reicht der Standard Classloader.

Um also in einem Ressourcen sowohl im Entwicklungsprojekt als auch in der Jar später (und vor allem: in dem Multi-Jar-Archiv mit FatJar, siehe oben) zu benutzen, bedarf es folgender Konfiguration:

• In der Regel existiert ein Verzeichnis src, wo die Packages der eigenen Java-Dateien liegen. Dort einen Verzeichnis (Beispiel: images) anlegen, oder natürlich auch als Unterverzeichnis in einem Package (ist ja auch ein Verzeichnis).
• Um in Java nun beispielsweise das Bild image.png aus dem Verzeichnis images zu laden, macht man folgendes: URL url = classLoader.getResource("images/image.png"). classLoader ist dabei der Standard-Classloader; diesen erhält man beispielsweise durch classLoader = MyClass.class.getClassLoader() wobei MyClass eine Klasse aus dem eigenen Projekt ist, die den Standard-ClassLoader verwendet. Das vollständige Beispiel zum Laden eines Bildes wäre also: Icon icon = new ImageIcon(MyClass.class.getClassLoader().getResource("images/image.png"));

Problem 3a: Der Buildprozess

Jedes Mal, wenn man eine Änderung am Projekt gemacht hat, muss das gesamte Projekt exportiert werden. Zum Beispiel mit dem o.g. FatJar-Plugin. Jedes Mal müssen die Einstellungen geprüft werden und eventuelle Sonderkonfigurationen wie Classpath-Erweiterungen oder Zusatzressourcen eingestellt werden. Dies ist nicht nur lästig und zeitaufreibend – es ist auch schlichtweg unnötig. Die Antwort darauf ist: Ant.

Ant ist die moderne Antwort auf make. Während make auf Kommandozeilen orientierte Konfiguration und auf Basis von Leerzeichen/Tabulatoren arbeitet, wird ant mittels XML “geschrieben”. Nicht ohne Grund verwendet Eclipse für die internen Buildprozesse “rein zufällig” auch Ant – und es lässt nicht überraschen, dass Eclipse auch externe Ant-Tasks ausführen kann. Für Unwissende: Das ist das dritte Icon oben, Debug, Run und eben Run Tool/External Tools wie etwa Ant-Tasks.

Im Wesentlichen ähnelt Ant dabei sehr an make. Es werden einzelne Targets und untereinander zusammenhängende Abhängigkeiten definiert. Auch können wahlweise Systemkommandos ausgeführt werden (ggf. plattformabhängig). Des Weiteren gibt es zu der großen Ant-Befehls-Library zahlreiche Plugins.

Das FatJar Plugin bietet beim Export-Prozess die Möglichkeit, die Konfiguration auch als build.xml zu speichern. Damit erhält man eine Grundlage. Wie man auch ohne Kenntnisse von FatJar und Ant leicht erkennen kann, werden alle Jars zusammengepackt und an das Plugin geschickt. Der fertige Name wie auch die Main-Klasse können theoretisch noch angepasst werden. Kleiner Test? Einfach auf diese build.xml > Rechte Maustaste > Run ausführen. Voilá. Damit hat man mit einem Knopfdruck immer ein aktuelles Jar.

Problem 3b: Keine Testfälle

In das exportierte Jar gehören in Regel mindestens keine Testfälle – und zusätzlich kann man sich eine Jar (nämlich junit) sparen. Dafür müssen alle Class-Dateien in ein seperates Verzeichnis kopiert werden. In einem Standardprojekt liegen im Verzeichnis src die Codedateien, im Verzeichnis bin die kompilierten Bytecodedateien. Als Zwischenschritt kopieren wir alle Dateien von bin nach build – aber mit einer definierten Ausnahmeliste: Alle Pfade, die mit tests beginnen oder mit test(s) aufhören, werden ignoriert. Die Muster mit Wildcards sind leicht zu verstehen und selber anpassbar.

<mkdir dir="build" />
<copy todir="build">
<fileset dir="bin">
<exclude name="tests/**/*.*"/>
<exclude name="**/test/*.*"/>
<exclude name="**/tests/*.*"/>
</fileset>
</copy>;

Zunächst wird das Verzeichnis gelöscht (von einem vorherigen Task) und anschließend werden die Dateien kopiert. Die Ant-API sei auch an dieser Stelle erwähnt.

Das XML von FatJar muss nun natürlich geringfügig angepasst werden: Statt aus bin muss jetzt build im Filesourcepath stehen: <fatjar.filesource path="build" relpath=""/>

Problem 4: Zusatzinformationen im Buildprozess

Vor allem in der Entwicklungszeit – vielleicht aber auch danach für den Support – möchte man im Buildprozess einige Zusatzinformationen speichern. In dieser Kurzvorstellung gehe ich auf zwei interessante Möglichkeiten ein: Das Datum und die Uhrzeit des Buildens und die aktuelle Revision des Subvision-Repository.

Als Ausgabe definieren wir eine Property-Datei, die von Java aus sehr einfach mit der Klasse Properties oder ResourceBundle gelesen werden kann. Ant kann ebenfalls Property-Dateien lesen und schreiben.

Mit dem XML-Schnippsel <tstamp><format property="TSTAMP" pattern="MM/dd/yyyy HH:MM:SS z"/></tstamp> legen wir eine lokale Variable namens “TSTAMP” an, die durch den Ant-Befehl tstamp und format ausgefüllt wird. Hier ein standardisiertes Format, damit es Java auch entsprechend einfach wieder lesen kann. Wer mag, kann dies (beidseitig) auch ändern.

Für die aktuelle SVN-Revision bedarf es einem Plugin. Theoretisch könnte man auch ein Ant-Befehl “svn info” losschicken, aber dafür muss sowohl das Programm svn lokal verfügbar sein (in Eclipse nicht zwingend notwendig) als auch in der richtigen Version. Stichwort hier: SVN 1.4 != 1.5. Glücklicherweise bietet tigris.org ein entsprechendes Plugin unter dem Namen SvnAnt an. Entweder man kopiert sich das Plugin in den Ant-Classpath.. oder einfach in das Projekt selber. Im Beispiel gehe ich davon aus, dass das Plugin unter build_data/svndata-1.2.1 extrahiert wurde.
Das Plugin muss zunächst im project bekannt gemacht werden, das sieht in Ant etwa so aus:

<!-- svn ant integration -->
<path id= "svnant.classpath" >
<fileset dir= "build_data/svnant-1.2.1/lib" >
<include name= "*.jar" />
</fileset>
</path>
<typedef resource="org/tigris/subversion/svnant/svnantlib.xml" classpathref="svnant.classpath" />

An der Stelle (sprich: in dem Task) wo man die Information braucht, reicht dann beispielsweise folgender Aufruf, um eine Ant-Variable svn.revision zu setzen.

<svn>
<status path="src/" revisionProperty="svn.revision" />
</svn>

Es stehen natürlich auch andere Informationen zur Verfügung, dazu bitte die entsprechenden Dokumentationen von Subversion oder SvnAnt konsultieren.

Die nun zwei gewonnen Informationen РTSTAMP und svn.revision Рk̦nnen nun in eine Property-Datei geschrieben werden. Dies geht wirklich sehr einfach mit:

<propertyfile file="build/configuration.properties">
<entry key="buildRevision" value="${svn.revision}"/>
<entry key="buildDatetime" value="${TSTAMP}"/>
</propertyfile>

Das war’s schon. Idealerweise sollte das Java-Programm diese Informationen natürlich nur optional verwenden, da sie ja zur Laufzeit in Eclipse selber nicht vorhanden sind. Erst nach dem Export werden diese Informationen gesetzt. Wie bereits in 3b erwähnt, werden die Dateien im Verzeichnis build zusammengefügt. Natürlich muss das Schreiben der Property-Datei vor dem Zusammenfügen mittels FatJar passieren.