Hi,
Ich hab für den Java Client aus meinen Webservices Beispielen für Domino 7 ein ant-build Skript erstellt. Ich halte solche Tools für typisch Java (also großartig). Ich will das hier deshalb ein bischen näher erläutern. Die entsprechende Datei (build.txt -> muß in build.xml umbenannt werden), findet ihr hier (
http://atnotes.de/index.php?topic=26569.msg169997#msg169997). Das ist auch ein konkreter Anwendungsfall. Die beiden angehängten Datein build.txt und das zip müssen in das gleiche Verzeichnis runtergelaten werden. build.txt muß wie erwähnt in build.xml umbenannt werden.
Dieses spezifische, von mir erstellte build.xml führt die folgenden Operationen durch, um einen build für einen Java-Webservice Client durchzuführen:
1. Es läd die für den Webservice benötigten Zusatzjar Files aus dem Internet und legt sie auf dem lokalen Rechner ab.
2. Es entzippt eine Reihe von mir in einer zip-Datei abgelegten Java-Source Dateien (für den Webservices Client) und packt sie in ein relatives Verzeichnis src.
3. Es kompiliert gerade in src entpackten Java-Source Dateien in ein relatives Verzeichnis build und benutzt die in (1) runtergeladenen Zusatz-Libraries.
4. Eine Grafik-Datei (jpg) wird aus dem src Verzeichnis in das build Verzeichnis kopiert.
5. Die gerade kompilierten Java Dateien werden gestartet und der Webservice Client erscheint auf dem Bildschirm.
Dies alles wird durch den Befehl ant gestartet und erfordert keine weitere User-Interaktion.
Mit Ant können also verschiedene Aufgaben, die mit kompilieren und ausliefern von Software verbunden sind auf einfache Art und Weise lösen. Ant ist kein Installer. Ein build-tool ist für einen Entwickler und nicht einen Endanwender. Natürlich kann man ant auch als Installer verwenden, aber das ist nicht die Hauptaufgabe.
In C gibt es seit Jahren ein ähnliches Tool namens make.
Zunächst muß ant auf dem lokalen Rechner installiert werden.
Das Tool kann einfach als zip von apache runtergeladen und entpackt werden (
http://ant.apache.org/). Dann sind noch einige wenige Umgebungsvariablen zu setzen. (Infos hier:
http://ant.apache.org/manual/index.html -> der Installing link)
Für Windows geht das so:
Assume Ant is installed in c:\ant\. The following sets up the environment:
set ANT_HOME=c:\ant
set JAVA_HOME=c:\jdk1.2.2
set PATH=%PATH%;%ANT_HOME%\bin
In Windows ist es schlau, diese Variablen in Systemsteuerung/System/Umgebungsvariablen einzutragen.
Dann kann man in einer xml-Datei festlegen, wie der build von statten geht.
Will man eine spezifische Aufgabe mit ant lösen, schreibt man für diese Aufgabe eine Datei build.xml. Hier sind die spezifischen Schritte festgelegt, die ant abarbeiten soll.
Mit installierten ant und der spezifischen build.xml muß der user
1. nur noch zum Verzeichnis wo er das build.xml hingelegt hat per cmd prompt hingehen,
2. ant eingeben und return drücken.
3. Die ganzen im build.xml definierten, langweiligen Schritte erledigt dann ant. Im schwarzen jpg unten sieht man ant bei der Arbeit, d.h. die Ausgabe im cmd prompt.
Ich beschreibe jetzt die einzelnen Schritte des build.xml Files für das Webservice Client Projekt. Wie gesagt findet ihr das gesamte File als Attachment in diesem Posting (build.txt in build.xml umbenennen, atnotes akzeptiert keine .xml Attachments:
http://atnotes.de/index.php?topic=26569.msg169997#msg169997 Erst werden ein paar Variablen deklariert:
<property name="build.dir" location="build"/>
<property name="lib.dir" location="lib"/>
<property name="src.dir" location="src"/>
<path id="project.classpath">
<pathelement location="${build.dir}"/>
<fileset dir="${lib.dir}">
<include name="*.jar"/>
</fileset>
</path>
Die beiden Variablen build.dir und lib.dir wurden in den oberen Zeilen als relativer Pfad deklariert. Sie werden später im File referenziert.
Variablen werden mit funny "${name}" Syntax referenziert. (location="${build.dir}").
Etwas komplizierter ist path. Damit deklariere ich hier den Classpath für das Projekt. Ich wiederhole das hier noch mal:
<path id="project.classpath">
<pathelement location="${build.dir}"/>
<fileset dir="${lib.dir}">
<include name="*.jar"/>
</fileset>
</path>
Heisst:
Zum classpath gehört:
1. Alles im Verzeichnis build.dir (pathelement)
2. alle Dateien, die mit .jar enden im lib.dir (fileset)
Danach besteht ein ant-Deskriptoren-File (build.xml) aus einer Kette von Tasks, die voneinander abhängen.
In dem Beispiel wird im project-Element oben excecute als default-target deklariert.
<project name="kind_of_build" default="execute" >
Excecute hängt aber von copy ab.
<target name="execute" depends="copy" description="Runs the program">
Das heisst wenn ich durch den Befehl ant den Build starte, wird execute aufgerufen. Der hängt aber von copy ab. Also wird copy aufgerufen. In dem Beispiel hangeln sich so die Task-Ausführung immer weiter nach oben. Sie beginnt oben und geht dann wieder runter.
execute hängt von copy ab
copy hängt von compile ab
compile hängt von unzip ab
unzip hängt von download ab.
Wenn also execute gestartet wird, wird zunächst download (Ende der Kette) ausgeführt und dann nacheinander unzip, compile, copy und execute.
Was machen nun die einzelnen tasks.
1. download:
<target name="download" depends="prepare">
<get usetimestamp="true" src="http://www.ibiblio.org/maven/jgoodies/jars/forms-1.0.5.jar" dest="lib/forms-1.0.5.jar" verbose="true" />
<get usetimestamp="true" src="http://cvs.sourceforge.net/viewcvs.py/*checkout*/jgnash/jgnash/lib/looks-1.3.2.jar?rev=1.1" dest="lib/looks-1.3.2.jar" verbose="true" />
<get usetimestamp="true" src="http://www.ibiblio.org/maven/xml-apis/jars/xml-apis-2.0.2.jar" dest="lib/xml-apis-2.0.2.jar" verbose="true" />
<get usetimestamp="true" src="http://www.ibiblio.org/maven/axis/jars/axis-1.3.jar" dest="lib/axis-1.3.jar" verbose="true" />
<get usetimestamp="true" src="http://www.ibiblio.org/maven/axis/jars/axis-ant-1.3.jar" dest="lib/axis-ant-1.3.jar" verbose="true" />
<get usetimestamp="true" src="http://www.ibiblio.org/maven/axis/jars/axis-jaxrpc-1.3.jar" dest="lib/axis-jaxrpc-1.3.jar" verbose="true" />
<get usetimestamp="true" src="http://www.ibiblio.org/maven/axis/jars/axis-saaj-1.3.jar" dest="lib/axis-saaj-1.3.jar" verbose="true" />
<get usetimestamp="true" src="http://www.ibiblio.org/maven/axis/jars/axis-wsdl4j-1.3.jar" dest="lib/axis-wsdl4j-1.3.jar" verbose="true" />
<get usetimestamp="true" src="http://www.ibiblio.org/maven/commons-discovery/jars/commons-discovery-0.2.jar" dest="lib/commons-discovery-0.2.jar" verbose="true" />
<get usetimestamp="true" src="http://www.ibiblio.org/maven/xerces/jars/xerces-2.4.0.jar" dest="lib/xerces-2.4.0.jar" verbose="true" />
<get usetimestamp="true" src="http://www.ibiblio.org/maven/commons-logging/jars/commons-logging-1.0.4.jar" dest="lib/commons-logging-1.0.4.jar" verbose="true" />
<get usetimestamp="true" src="http://cvs.sourceforge.net/viewcvs.py/*checkout*/cc-config/swing-gui/3rdparty/foxtrot.jar?rev=1.2" dest="lib/foxtrot-2.0.jar" verbose="true" />
</target>
Über den get Befehl werden eine Reihe von Zusatzlibraries (in Java .jar-Dateien) von verschiedenen Servern im Internet automatisch runtergeladen (src=)und in das lib-Verzeichnis getan (dest=). Das Ding funktioniert inkrementell. Wenn das Erstelldatum der Datei im Internet genauso alt ist wie eine evtl. im lib-Verzeichnis schon vorhandene, wird nicht runtergeladen (ist ja auch nicht notwendig).
2. unzip
Dann wird im unzip Task die von mir ausgelieferte zip Datei entpackt die einzelnen .java Sourcen und in das src-Verzeichnis getan.
Eingeschlossen von dieser Operation sind alle Dateien (include name="**/*.*") ausser .java-Dateien, dernen Name mit Test anfängt (exclude name="**/Test*.java"). Das wären dann sogenannte Junit-Test Dateien. Hab aber in diesem Projekt noch gar keine Junit-Tests, so dass das ein bischen Nonsens und völlig unnötig ist (Gewohnheit).
<target name="unzip" depends="download">
<unzip src="aja_jSwing_client_domino_ws_0.2.zip" dest=".">
<patternset>
<include name="**/*.*"/>
<exclude name="**/Test*.java"/>
</patternset>
</unzip>
</target>
3. compile
Im compile-Task werden die Java-Sourcen kompiliert. Als Classpath wird der oben unter den globalen Variablen deklarierte project.classpath genommen (wurde ganz oben erklärt).
Die kompilierten class-Dateien werden in den build.dir gepackt.
<target name="compile" depends="unzip" description="Compiles the source code">
<javac srcdir="${src.dir}" destdir="${build.dir}">
<classpath refid="project.classpath"/>
</javac>
</target>
4. copy
Zusätzliche ressourcen wie z.B. Icons als .gif Dateien werden von Java nicht kompiliert. Die müssen von dem src dir in das build dir kopiert werden. Das macht der copy task. Ausgeschlossen werden alle Dateien mit einer .java Endung, weil schon der Compiler aus den .java Dateien die .class Dateien ins build.dir gepackt hat (compile-task, s.o.). So wird nur das .gif kopiert.
<target name="copy" depends="compile" description="copies non java files from src to build">
<copy todir="${build.dir}">
<fileset dir="${src.dir}">
<exclude name="**/*.java"/>
</fileset>
</copy>
</target>
5. execute
Als letztes wird dann das eben entzippte und kompilierte Java Programm gestartet:
Die folgenden Zeilen sagen ungefähr. Benutze den oben festgelegten Classpath und starte die main-Methode der Klasse de.aja.ws.sample.ui.swing.Launcher in einer eigenen Java Virtual Maschine Instanz (fork = yes).
<target name="execute" depends="copy" description="Runs the program">
<echo level="warning" message="running" />
<java classname="de.aja.ws.sample.ui.swing.Launcher" fork="yes">
<classpath refid="project.classpath"/>
</java>
</target>
In diesem Projekt wurden nur javac, copy, unzip, java tasks verwendet (und einige weitere ant-Befehle wie fileset und echo).
Es gibt noch total viele weitere vordefinierte Tasks, die mit ant verwendet werden können. (hier auf ant-tasks link klicken:
http://ant.apache.org/manual/index.html). Das sind nur die Standardsachen. Es existieren Tonnen von optional bonuns packages. Und zwar nicht nur die, die im optional packages im Ant Projekt sind. Ant ist open Source und modular aufgebaut. Ant kann und wird sehr stark erweitert. Jeder kann das machen, wenn er es kann.
Ach ja. Eclipse hat seit 3.0 einen Editor für ant build.xml Dateien Jemand hat auf javablogs angekündigt, dass in Kürze ein Artikel von ihm darüber in ibm-developerworks erscheinen wird. Ich bin aber auch so klargekommen. Der Editor ist mit sehr umfangreicher code completion, farbliches Highlighten (kommt im jpg unten nicht so raus), einer outline und einen Debugger (hab ich nicht gebraucht).
Gruß Axel
