Fünf Ant-Tips aus der Praxis

von Stefan Edlich, Autor von Ant - kurz & gut

Mit den folgenden Tips möchte ich den an Ant interessierten Lesern einige der Erfahrungen aus meiner praktischen Arbeit mit diesem Build-Tool an die Hand geben. Ich hoffe, daß Ihnen diese Anregungen helfen, Ant besser zu verstehen und einzusetzen. In dem Bändchen Ant - kurz & gut finden Sie eine kurze Einführung in die Arbeit mit Ant und eine Task-Referenz. Wer sich tiefergehend mit Ant und mit Erfahrungen aus großen Projekten beschäftigen möchte, dem sei Ant: The Definitive Guide von Jesse Tilly & Eric Burke ans Herz gelegt.

Tip 1: Setzen Sie Optional Tasks, java und exec ein

Man kann in Ant nicht alle anfallenden Aufgaben mit Build-in Tasks erledigen. Bei komplexeren Projekten stößt man recht schnell an die Grenzen dieser Tasks. Oft hilft es hier, einen Blick auf die ständig wachsende Zahl von nützlichen Optional Tasks zu werfen, die beispielsweise die Arbeit mit JUnit und ftp ermöglichen. Mit dem Optional Task script können sogar in Programmiersprachen wie JavaScript, VBScript, Perl, TCL oder Python geschriebene Skripten ausgeführt werden (siehe dazu auch http://www-124.ibm.com/developerworks/projects/bsf).

Müssen keine oder nur wenige Informationen mit Ant ausgetauscht werden, bietet es sich an, Java-Programme mit dem Task java aus dem Buildfile heraus aufzurufen, oder auch Systemkommandos oder andere Programme wie z.B. Shell-Skripten mit dem Task exec. Die Ausgabe des aufgerufenen Programms können Sie über eine Property in Ihrem Buildfile weiterverwenden:

<exec dir="${src}" executable="cmd.exe"
os="Windows 2000" outputproperty="DIRCONTENT">
    <arg line="/c dir"/>
</exec>

Ansonsten bietet Ant Ihnen auch die Möglichkeit, eigene Tasks zu schreiben. Mehr dazu finden Sie im folgenden Tip.

Tip 2: Schreiben Sie eigene Tasks

Da Ant ein einfaches Attributhandling über getter/setter-Methoden erlaubt, ist das Schreiben eigener Tasks wirklich einfach. Ihre Tasks müssen von der abstrakten Klasse org.apache.tools.ant.Task abgeleitet werden und die execute()-Methode implementieren. Wenn Sie ein Attribut XYZ übergeben wollen, müssen Sie eine setXYZ()-Methode schreiben, in der das Attribut gesetzt wird. Anschließend müssen Sie den Task im Buildfile nur noch über Taskdef bekannt machen, um ihn unter seinem Namen verwenden zu können. So einfach ist das. Beispiele dazu finden sich in meinem Buch oder im Web auf der Jakarta-Ant-Site.

Ant bietet hier aber noch mehr: Über das project-Objekt, auf das alle Tasks Zugriff haben, lassen sich gleichzeitig mehrere neue Properties setzen. Damit kann ein Task quasi mehrere Rückgabewerte haben.

Wenn Sie eigene Tasks geschrieben haben, sollten Sie überlegen, ob sie nicht auch für andere Entwickler interessant sein könnten, und sie ggf. der Open Source-Gemeinde zu Verfügung stellen (Posting, Webseite oder "Get Involved" auf der Jakarta-Ant-Site).

Tip 3: Lagern Sie Property-Definitionen aus

Auf den ersten Blick klingt das wie eine Selbstverständlichkeit. Es zeigt sich aber, daß fast alle Ant-Einsteiger Properties zunächst einmal in build.xml setzen. Bei umfangreicheren Projekten werden die XML-Files dann schnell unübersichtlich. Properties können nicht so einfach wiederverwendet werden und müssen oft mehrfach definiert werden, wenn man Buildfiles ausgelagert. Deshalb sollte jedes Buildfile mit der Anweisung

<property file="Dateiname"/>

beginnen. In dieser Datei werden nur die Namen der Properties und ihre Werte in der Form 'name=wert' angegeben. Außerdem können mit dem Zeichen # beginnende Kommentare einfügt werden. Eine Erläuterung der Properties ist hier viel einfacher und passender als in der XML-Datei.

Tip 4: Sorgen Sie für Wiederverwendbarkeit

Modularisieren Sie die Buildfiles. Das macht es nicht nur einfacher, Build-Dateien wiederzuverwenden, sondern erhöht auch die Lesbarkeit. Ab einer gewissen Größe werden Buildfiles so unübersichtlich, daß man schnell den Überblick verliert. Es gibt Buildfiles von über 40k (z.B. JBoss), meiner Ansicht nach nimmt aber die Lesbarkeit von ca. 10k an deutlich ab.

Mit der Anweisung

<ant antfile="subproject/property_based_subbuild.xml">
   <property name="param1" value="version 1.x"/>
...
</ant>

können andere Buildfiles aufgerufen werden. Wenn es erforderlich sein sollte, ist es auch möglich, ihnen spezielle Properties zu übergeben.

Die Wiederverwendbarkeit des Codes kann auch durch weitere Maßnahmen erhöht werden. So sollten Sie vermeiden, ähnliche Targets zu schreiben, wenn sie ähnliche Aufgaben zu erledigen haben. Versuchen Sie stattdessen, nur ein Target zu schreiben und dabei Parameter einzusetzen. Beispielsweise können Verzeichnisse als Parametervalue übergeben oder der Ablauf im Zieltarget mit Parametern durch if und unless gesteuert werden. Das Target kann dann auf folgende Weise mit den Parametern aufgerufen werden:

<antcall="targetName">
    <param name="pname" value="pvalue"/> ... 

Das hilft Code-Redundanzen zu vermeiden - und die Dateien werden kleiner.

Tip 5: Generieren Sie Ant-Code

Viele Aufgaben wie Kompilieren, Dokumentieren mit javadoc, Kopieren oder Löschen lassen sich gut standardisieren und automatisieren. Dazu ist es nicht immer notwendig, Buildfiles von Hand zu schreiben. Der benötigte Code kann oft auch durch Templates oder mit Hilfe anderer Programme (awk, sed, XSLT, selbstgeschrieben etc.) generiert werden. Mit der seit längerem angekündigten grafischen Oberfläche Antidote soll das Generieren von Buildfiles in Zukunft noch bequemer werden, aber es wird sicher bald auch andere Werkzeuge geben, die einem diese Aufgaben erleichtern.

Sie sollten sich allerdings genau überlegen, ob das Generieren von Buildfiles bei Ihrem Projekt tatsächlich sinnvoll ist. In der Regel eignet es sich vorwiegend für einfachere Aufgaben. Wenn man versucht, mit generiertem Code auch komplexere Aufgaben zu bewältigen, muß man häufig von Hand nachbessern. Dieses Nachbessern kann aufwendiger sein, als das Buildfile direkt von Hand zu schreiben.

Zum Schluß noch ein Hinweis