Java-Applikation als Mac-Anwendung deployen (Ant)

Wie bereits berichtet, ist es von Vorteil, der Buildprozess mit einem Ant-Script zu automatisieren. Um eine Mac-Application zu erstellen, muss man nur wissen, wie eine solche Application aufgebaut ist.. der Rest ist ein Klacks.

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>

Automatischer Deploy von Java-Applikationen oder: Ant Builds mit externen Jars und SVN-Informationen

Der Eclipse-verwöhnte Programmierer braucht sich eigentlich nicht mit Begriffen wie Deploy oder Build herumschlagen — zumindestens nicht so lange man in der Entwicklung ist. Ein Knopfdruck auf „Run“ und das Programm läuft. Sowohl alle lokalen Resourcen als auch alle externen Jars werden gefunden, eingebunden und können einwandfrei genutzt werden.

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?

„Automatischer Deploy von Java-Applikationen oder: Ant Builds mit externen Jars und SVN-Informationen“ weiterlesen

Neue Reihe „Diplomarbeit.. ftw!“

da-build-160409-01

So, wenn man spontane Ideen hat, sollen sie ja ganz gut sein. Fein, der Titel ist ‚mal ganz spontan entstanden, weil mir nichts besseres eingefallen ist. 🙂

Seit diesem Monat stecke ich in meiner Diplomarbeit: Die Entwicklung eines Tools, mit dem man die Abhängigkeiten von Views und

Triggern in einer Datenbank analysiert, parst und anschließend visuell (sprich in Graphen) anzeigt. Das ganze muss auch persistent gespeichert werden, da der Prozess je nach Größe der Datenbank etwas dauern kann.

Für rund vier Wochen intensiven Arbeitens (zu zweit) hat unsere in Java geschriebene Applikation bereits große Fortschritte gemacht. Sowohl das Auslesen als auch das Parsen von mehrschichtigen Views klappt, als auch das Lesen und Speichern in einen nichtflüchtigen Speicher (HSQLDB). Außerdem haben wir bereits einen Prototypen zur Visualisierung.

Anbei einen Screenshot der aktuellen Build (Mac OS X). Die Anwendung sieht unter einem Mac leider immer noch sehr „Java“ aus. Die Menubar habe ich zwar bereits nach oben „verdonnert“, aber es reicht nicht aus. Abhilfe schafft hier das das Projekt MacWidgets, das eine Reihe von Swing-Komponenten selbst zeichnet. Mit dem optionalen Code da-build-160409-02sieht die Anwendung bereits etwas schniker aus.

Weitere technische Details zur Anwendung:

  • HSQLDB als lokale Datenbank zum Ablegen der Schemata und Datenbankverbindungen
  • Hibernate als OR-Wrapper um Hibernate; die Anwendung produziert 0 Sql-Statements
  • JUNG2 als Graphenframework zum Zeichnen der Elemente (späterer Blogeintrag wird dies zeigen)
  • JavaBuilders/SwingX als idealer Layouter für Formulare, wie unseren Connectiondialog (späterer Blogeintrag wird dies zeigen)

Java: Nativer Dateidialog unter MacOS X

Definitiv in der Kategorie: „Was ich schon immer mal wissen wollte..“

Wenn man mit Java Swing ein JFileChooser verwendet, so sieht der unter MacOS X alles andere als schön aus – und nativ ist er sowieso nicht. Was ich nicht wusste: Apple hat das AWT-Pendant FileDialog nativ implementiert (oder nachgebaut?). Gewusst wie – darauf gekommen bin ich auch nur, weil ich einfach mal gesucht habe.

Edit: Wie es aussieht, sieht der FileDialog auch unter Windows besser als sein Swing-Pendant aus. Wie sieht das mit den anderen System aus?

Statische Code-Analysetools für Java

Um die Softwarequalität zu verbessern, werde ich mir in den nächsten Java-gestützen Projekten einmal diese beiden Tools angucken. Im Vergleich schneidet PMD etwas besser als FindBugs ab, wir werden es sehen.

Ernüchterned ist es ja schon irgendwie, wenn man sein Fehler- und Warnungsfreie Projekt (Eclipse Compiler läßt grüßen) damit checkt und vor Hunderten Fehlern steht..