Open Source im professionellen Einsatz

Ant: Java ist anders

Dass Make seine Schwächen hat, war auch schon vor Java bekannt. Mit Java hat aber ein Grundkonzept von Make seine Gültigkeit verloren. Java-Quellcode-Dateien können nicht nur in einem zirkulären, sondern sogar in einem zum Kompilationszeitpunkt undefinierten Abhängigkeitsverhältnis stehen. Make kann also auch kein minimales Set an auszuführenden Kommandos berechnen, sondern muss alle Quelldateien sowieso erneut kompilieren.

Damit lag es nahe, ein neues, auf Java ausgerichtetes Buildtool zu entwerfen. Da auch XML aus derselben Technologiegeneration wie Java stammt, ist das Ergebnis eine in einer XML-Sprache definierte Buildanweisung, die ein Java-Programm (nach der fleißigen Ameise Ant genannt) verarbeitet. Logischerweise nennt sich das »Makefile« hier dann auch »build.xml« .

Leider ist XML eine Dokumentensprache und keine Programmiersprache und gedacht für den Informationsaustausch zwischen Computerprogrammen. Damit hat Ant ähnliche Probleme wie Make. Für Entwickler ist das Schreiben von Ant-Makefiles trotz aller Editor-Unterstützung für XML eine fehleranfällige Geschichte. Außerdem ist die Formulierung etwa von Bedingungen und Schleifen innerhalb der Buildanweisungen etwas gestelzt. Listing 1 zeigt ein Beispiel aus einer »build.xml« .

Listing 1

Ausschnitt aus einem Ant-Buildfile

01 <target name="compile-tools" description="Compile taglet/doclet">
02       <fail message="property jdk.home is undefined!" unless="jdk.home"/>
03       <mkdir    dir="${build.home}/tools"/>
04       <javac srcdir="${src.home}"
05             destdir="${build.home}/tools"
06            includes="de/bablokb/tools/**"
07        classpathref="classpath.tools"
08               debug="${compile.debug}"
09         deprecation="${compile.deprecation}"
10            optimize="${compile.optimize}">
11       </javac>
12 </target>

Der Java-Standard

Trotz aller Nachteile ist Ant einer der De-facto-Standards für die Java-Entwicklung. Es hat sich durchgesetzt und eine eigene Abstammungslinie für weitere Buildtools angestoßen, weil es per Plugins erweiterbar ist, seine Java- und XML-Zentriertheit eine gute Tool-Integration erlaubt und dadurch gerade im Zusammenspiel in größeren Umgebungen mit weiteren Komponenten Teil eines sehr mächtigen Entwicklungs- und Buildsystems sein kann. Ein oftmals entscheidender Punkt, der über die rein technischen Aspekte hinausgeht, ist aber die Erweiterung der Perspektive von Buildtools und Buildsystemen auf die Bedürfnisse großer Unternehmen, die insbesondere die großen Enterprise-Java-Umgebungen vorangetrieben haben.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 7 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Als digitales Abo

Als PDF im Abo bestellen

comments powered by Disqus

Ausgabe 07/2013

Preis € 6,40

Insecurity Bulletin

Insecurity Bulletin

Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...

Linux-Magazin auf Facebook