Tutorial

In diesem Tutorial wollen wir ein Installations-Archiv für eine einfache Java Applikation bauen. Unsere Applikation soll aus folgenden Teilen bestehen

• ein 'JAR'-Archiv 'demoapp.jar', das die Klassen- und andere Dateien der Applikation enthält.
• die Dokumentation in einer HTML-Datei sowie ein paar GIF-Dateien.
• eine README Datei.
• eine Datei für die Software Lizenz.
• und weil unsere Applikation freie Software ist, sollen die Quellen auch im Archiv enthalten sein.

Inhalt

1. Schritt- Vorbereiten der Applikation

Es ist daher keine gute Idee, feste Pfade in die Applikation einzubauen. Am einfachsten löst man so ein Problem, indem man diese Pfade in eine Property-Datei ablegt - bleibt noch das Problem wo denn nun diese Property-Datei abgelegt wird.

LiftOff sorgt dafür, daß die Applikation mit einem System-Property 'datadir' gestartet wird, das den Pfad zum Daten-Verzeichnis enthält. Um eine Property Datei zu laden, kann man zum Beispiel folgendes Programmstückchen verwenden

Datei props.snip

public class MyProperties extends Properties {     public void load( String fileName ) {         InputStream is = null;         // try to load from the users home dir         try {             String propfile  = fileName;             String dataDir = System.getProperty("user.home");             if( dataDir != null ) {                 if( ! dataDir.endsWith(File.separator))                     dataDir += File.separator;                 propfile = dataDir + propfile;                 is = new FileInputStream(propfile);                 System.err.println("use props from users home " + dataDir );             }         } catch( IOException e ) {             is = null;         }         // try 'datadir'         try {             String propfile  = fileName;             String dataDir = System.getProperty("datadir");             if( dataDir != null ) {                 if( ! dataDir.endsWith(File.separator))                     dataDir += File.separator;                 propfile = dataDir + propfile;                 is = new FileInputStream(propfile);                 System.err.println("use props from data dir " + dataDir );             }         } catch( IOException e ) {             is = null;         }         // try classpath         if( is == null ) {             is = ClassLoader.getSystemResourceAsStream(fileName);             System.err.println("use props from classpath ");         }         try {             if( is != null ) {                 load(is);             }         } catch (IOException e ) {             System.err.println("can not load properties : " + e );             System.err.println("    use defaults");         }     } }

Der Installer kann bei der Installation eine 'Property'-Datei mit den richtigen Pfaden (und mit anderen Informationen) aus einer Vorlage-Datei erstellen, doch dazu später mehr.

2. Schritt - Definieren der Properties für den Installer

Diese Angaben werden in einer Property-Datei gespeichert, die später auch auch im Distributions-Archiv enthalten sein wird. Am einfachsten ist es, diese Datei mit dem builder-Programm zu erstellen.

Als erstes machen wir ein paar Angaben zu unserer Applikation. Die Angaben in den Feldern Author, Description und Version werden später auf der ersten Karte des Installers angezeigt.

Das Feld Java version required wird bei der Installation überprüft und nur wenn mindestens diese Version vorhanden ist, kann die Applikation installiert werden.

Das default prefix wird zum Konstruieren von Pfadnamen verwendet. Wird das Programm von einem Administrator auf einem UNIX-System installiert, ist z.B. die Voreinstellung für den Pfad für die Dokumentation /usr/doc/demoapp . Wird die Applikation von einem normalen Benutzer installiert, landet die Dokumentation in /home/.../demoapp/doc.

Die Felder License text und Readme text geben Dateien im Archiv an, die für die Lizenz bzw. die Readme-Datei verwendet werden sollen. Wir kommen später darauf zurück.

Die Angabe im Feld Extra file list sehen wir uns an, wenn wir die Programm-Quellen in das Archiv aufnehmen. Vorerst lassen wir es leer.

Pakete

Wir definieren also drei verschiedene Pakete, base für alles, was in jedem Fall installiert werden soll, doc für die Dokumentation und source für die Quellen unseres Programms.

Für jedes Paket müssen wir eine Beschreibung (Label) angeben und ob das Paket immer installiert werden soll (required=yes)

Installations typen

Java Archiv

Der Identifier darf nur aus Buchstaben, Ziffern und dem Unterstrich bestehen und muß innerhalb des Pakets eindeutig sein. Der Identifier wird für die Konstruktion von Property-Namen verwendet.

Als Typ wählen wir archive aus. Ausser dem Typ archive gibt es noch die Typen exec, file, lib und template, die wir später noch kennenlernen.

Das Feld location gibt an, worin wir unser Archiv installieren wollen, in diesem Fall handelt es sich um die Bibliothek, die unser Programm enthält. Solche Dateien sollten in jlib installiert werden.

Das Feld target name gibt an, wie die Datei nach der Installation heißen soll, im Feld source file gibt man die Datei an, die in die Distribution kopiert werden soll.

Archive werden übrigens automatisch in den Classpath der Applikation aufgenommen.

Programm

Im Feld java class geben wir an, welche Klasse die main-Methode der Applikation enthält, als location sollten wir für ausführbare Programme bin angeben, target name ist der Name, unter dem der Benutzer das Programm starten kann.

Die Felder template name und source file lassen wir leer, in diesem Fall wird je nach Betriebssystem ein passendes Template ausgewählt. Der Zweck dieser Felder wird noch klar werden, wenn wir uns mit Templates beschäftigen.

Dateien

Wir erzeugen also ein Installable file mit dem Bezeichner README, und wählen location doc. Für den target name geben wir README an und wählen im Feld source file die entsprechende Datei aus.

Für Datei LICENSE soll die Lizenz für unsere Demo-Applikation enthalten, führen wir die gleichen Schritte wie eben durch.

Property Templates

Wir benötigen diesen Mechanismus um unsere Property-Datei zu erstellen. Unsere Demo Applikation soll herausfinden können, wo die Hilfe-Dateien zu finden sind. Dazu nehmen wir die Property Datei (die wir zum Testen sicher schon erstellt haben) und ändern sie entsprechend ab.

Datei demoapp.prop

# properties for the demo application docdir=/usr/src/project/docs libdir=/usr/src/project/lib

Wir ersetzen hier die Pfadangaben durch Strings der Form @variable@ , wobei die Variable angibt, was während der Installation hier eingesetzt werden soll.

Als Variablen stehen zur Verfügung

• alle Java System Properties.
• die Pfade für die Installationsorte, location.doc enthält z.B. den Pfad zur Dokumentation.
• für jedes Paket eine Variable der Form package.name, die den Wert 'yes' liefert, wenn das Paket installiert wurde.
• alle Properties des Installers selbst.

Datei demoapp_prop.in

# properties for the demo application by @product.author@ docdir=@location.doc@ libdir=@location.lib@

Nun erzeugen wir noch ein Installable für das Template. Das funktioniert so ähnlich wie bei Dateien.

Das Template installieren wir unter data, target name gibt wieder an, wie die Datei nach der Installation heißen soll, template name gibt an, wie das Template im Archiv heißen soll (das muß nicht das gleiche sein) und source file ist wieder der Name der Datei auf dem Entwicklungssystem.

Templates können natürlich auch noch für andere Dinge verwendet werden, z.B. für die Readme-Datei.

Dateilisten

Für die Dokumentation und die Quellen unserer Applikation verwenden wir daher eine andere Möglichkeit, nämlich eine Dateiliste.

Eine Dateiliste ist eine Textdatei, bei der jede Zeile aus ein oder zwei Feldern besteht, die durch Leerzeichen getrennt sind. Beginnt eine Zeile mit dem @-Zeichen, gibt die Zeile das Paket und das Ziel (location) für die folgenden Dateien an, ansonsten handelt es sich um einen (oder zwei Dateinamen.)

Der erste Name gibt jeweils an, unter welchem Namen die Datei im Archiv und auf dem Zielsystem heisen soll, der zweite Name, falls vorhanden, gibt den Namen auf dem Entwicklungssystem an. Fehlt der zweite Name, wird automatisch der Name im Archiv auch für den Namen der Quelldatei verwendet.

Der Name im Archiv muß immer ein relativer Dateiname sein. Ist der Name der Quelldatei eine relative Angabe, wird er als relativ zum Verzeichnis der Dateiliste betrachtet.

Lange Rede, kurzes Beispiel : Wir wollen eine HTML-Datei und ein paar GIF-Bilder aus dem Verzeichnis doku/html und die Quellen aus dem Verzeichnis src/java in das Archiv aufnehmen. Wir erstellen also eine Dateilist

Datei demoapp.list

@source:source java/Main.java          src/java/Main.java java/SomeClass.java     src/java/SomeClass.java java/OtherClass.java    src/java/OtherClass.java @doc:doc doku.html               doku/html/doku.html pic1.gif                doku/html/pic1.gif pic2.gif                doku/html/pic2.gif

Das Erstellen der Dateiliste kann (und sollte) man natürlich automatisieren.

3. Schritt - Erzeugen des Archivs

Das Zip-Archiv enthält die gleichen Dateien wie die selbstextrahierende Klasse, mit Ausname der Dateien des Installers. Es ist darum etwa 100k Byte kleiner.

Wir wollen eine selbstextrahierende Java-Klasse erzeugen (wenn wir nur ein Zip-Archiv erstellen wollten, hätten wir das mit zip einfacher haben können ...)

Im Feld loader class geben Sie die Klasse an, die als Loader für den Installer dienen soll. Normalerweise ist das die Klasse, die mit dem Installer ausgeliefert wurde. Sie können hier aber einen anderen Loader angeben.

Im Feld output dir geben Sie das Verzeichnis an, in dem das fertige Archiv abgelegt werden soll. Der Dateiname des Archivs ist immer derselbe wie der des Laders. Mit OK wird das Archiv erstellt und es erscheint ein Protokoll-Fenster

letzte Änderung Mon Feb 28 06:24:23 2000 Andreas Hofmeister