Die Problemlösung ist die gleiche, wenn man ein ganz kaputtes Superdrive hat.

Idee 1: Remote Install oder in deutsch: Entfernte Installation

Dieses Feature wurde mit der Einführung des Macbook Airs in Leopard integriert – okay, fein, den Host könnte der iMac spielen. Leider scheint das entweder nicht funktionieren oder aber es funktioniert tatsächlich nur mit dem Macbook Air Geht nicht. Schade

Idee 2: Die Leopard-DVD vom iMac

Ja, geniale Idee.. nur (leider) sind die mitgelieferten DVDs allesamt OEM-Versionen, die jeweils nur für die Produktreihe funktionieren. Also mit anderen Worten: Einen anderen iMac kann ich Leopard installieren, für ein anderes Macbook hätt ich ein(en) Tiger im Angebot.. ach menno

Idee 2.5: Disc Target Mode

Nachdem die Installation der iMac-Leopard-DVD auf dem Macbook Pro die Installation verweigerte, kam mir eine Blitzidee: Targetmode. Damit startet man das Target (also das Macbook) in einen besonderen Bootstatus; zeitgleich verbindet man den Target mit dem Hostrechner (Mac) und kann von dort auf die Platten zugreifen (vgl. externe Platten). Da man bei einem Mac auf externe Platten wie die eigene zugreifen kann, kann man auch installieren. Und wenn man für den Host auch eine gültige Installations-CD hat (oder ein funktionierendes Laufwerk)… *freu*

Tatsache, man nehme also die Boot-DVD des Hosts (hier iMac), mit der man “booten & installieren darf”. Als Zielmedium wählt man aber die Platte aus, die auf dem Target liegt – sehr einfach an dem Symbol eines externen Datenträgers zu erkennen. Nicht vergessen, vor dem nächsten Neustart die Rechner alle auszumachen, Kabel raus.. neu starten.. und voila.

Der genaue Wortlaut der Meldung: exception: java.lang.RuntimeException: Non-Java exception raised, not handled! (Original problem: Error (10000) creating CGSWindow)

Nach ein bisschen Recherche mit dieser Meldung stieß ich dann auf diesen Thread, in welchem auch die Lösung parat steht: Zugriffsrechte reparieren lassen und rebooten. Warum man rebooten muss (man muss es, habe es ausprobiert), entzieht sich meiner Kenntnisse; vielleicht werden manche Ressourcen nur einmal geöffnet?

Eine Mac-Application ist ein Verzeichnis mit der Erweiterung .app. Die Struktur einer Application (wir nennen sie im Folgenden Application) sieht wie folgt aus:

• Application.app
  • Contents
    • Info.plist — Properties-Datei für die Anwendung und Java
    • MacOS — Verzeichnis
      • JavaApplicationStub — Bootloader für Javaprogramme
    • PkgInfo — Datei mit Entwicklerinfo
    • Resources — Verzeichnis mit dem eigentlichen Javaprogramm
      • Java
      • • Die Jars und so.

Den Bootloader befindet sich auf einem Mac in dem Ordner /System/Library/Frameworks/JavaVM.framework/Resources/MacOS/JavaApplicationStub.

Prinzipiell kann man sich diese Struktur komplett selber erstellen; es ist aber zu Empfehlen, den initialen Prozess durch das Programm /Developer/Applications/Utilities/Jar Bundler zu machen. Mit Hilfe dieses Programmes lässt sich für eine bereits fertige JAR die Application erstellen.

Anschließend kopiert man das erstellte Resultat – quasi als Vorlage – in ein Verzeichnis für die Builds. In meinem Fall in dem build_data Verzeichnis. Ein Ant-Task erstellt darauf hin im Verzeichnis deploy eine Application. Die Vorlage ist idealerweise auch im SVN und auch später noch veränderbar – beispielsweise durch das Ändern des Applicationicon, -titel oder anderen Einstellungen.

Wichtig 1: Bei Verwendung von FatJar muss man als Package für die Main den Bootloader von FatJar (com.simontuffs.onejar.Boot) verwenden. Dies erkennt das Programm Jar Bundler aber auch automatisch.

Wichtig 2: Beim Kopieren der Dateien kann es passieren, dass die Rechte an der JavaApplicationStub verloren gehen. Diese muss als ausführbar markiert sein. Ein entsprechender Ant-Befehl stellt das sicher.

<target name="makeMac" depends="makeNormal">
<copy todir="deploy/Application.app">
<fileset dir="build_data/Application.app"/>
</copy>
<!-- chmod the application stub file executable -->
<chmod file="deploy/Application.app/Contents/MacOS/JavaApplicationStub" perm="755"/>
<copy file="deploy/Application.jar" tofile="deploy/Application.app/Contents/Resources/Java/Application.jar" />
</target>

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.