TheNEXUS

Die Autoren dieses Buches haben kein Interesse daran, eine Fehde zwischen Apache Ant und Apache Maven zu entfachen, aber wir sind uns auch der Tatsache bewusst, dass die meisten Organisationen eine Entscheidung zwischen den beiden Standardlösungen treffen müssen: Apache Ant und Apache Maven. In diesem Abschnitt vergleichen und kontrastieren wir die Tools.

Ant zeichnet sich durch einen Build-Prozess aus, es ist ein Build-System nach dem Vorbild von makewith targets und dependencies. Jedes Ziel besteht aus einer Reihe von Anweisungen, die in XML kodiert sind. Es gibt eine copy Aufgabe und einejavac Aufgabe sowie eine jar Aufgabe. Wenn Sie Ant verwenden, geben Sie Antw spezifische Anweisungen für die Kompilierung und Verpackung Ihrer Ausgabe. Sehen Sie sich das folgende Beispiel für eine einfache build.xml-Datei an:

Eine einfache Ant build.xml-Datei.

<project name="my-project" default="dist" basedir="."> <description> simple example build file </description> <!-- set global properties for this build --> <property name="src" location="src/main/java"/> <property name="build" location="target/classes"/> <property name="dist" location="target"/> <target name="init"> <!-- Create the time stamp --> <tstamp/> <!-- Create the build directory structure used by compile --> <mkdir dir="${build}"/> </target> <target name="compile" depends="init" description="compile the source " > <!-- Compile the java code from ${src} into ${build} --> <javac srcdir="${src}" destdir="${build}"/> </target> <target name="dist" depends="compile" description="generate the distribution" > <!-- Create the distribution directory --> <mkdir dir="${dist}/lib"/> <!-- Put everything in ${build} into the MyProject-${DSTAMP}.jar file --> <jar jarfile="${dist}/lib/MyProject-${DSTAMP}.jar" basedir="${build}"/> </target> <target name="clean" description="clean up" > <!-- Delete the ${build} and ${dist} directory trees --> <delete dir="${build}"/> <delete dir="${dist}"/> </target></project>

In diesem einfachen Ant-Beispiel können Sie sehen, wie Sie Antexact genau sagen müssen, was zu tun ist. Es gibt ein Kompilierziel, das die javacAufgabe enthält, die den Quelltext im Verzeichnis src/main/java in das Verzeichnistarget/classes kompiliert. Sie müssen Ant genau mitteilen, wo sich Ihr Quellcode befindet, wo der resultierende Bytecode gespeichert werden soll und wie das Ganze in eine JAR-Datei verpackt werden soll. Es gibt zwar einige neuere Entwicklungen, die dazu beitragen, dass Ant weniger prozedural ist, aber die Erfahrung eines Entwicklers mit Ant besteht darin, eine in XML geschriebene prozedurale Sprache zu kodieren.

Vergleichen Sie das vorherige Ant-Beispiel mit einem Maven-Beispiel. Um in Maven eine JAR-Datei aus einer Java-Quelle zu erstellen, müssen Sie lediglich eine einfache pom.xml erstellen, Ihren Quellcode in${basedir}/src/main/java ablegen und dann mvn install über die Befehlszeile ausführen. Das Beispiel einer Maven pom.xml, die die gleichen Ergebnisse erzielt wie die einfache Ant-Datei, die in A Simple Ant build.xml file aufgeführt ist, wird inA Sample Maven pom.xml.

A Sample Maven pom.xml gezeigt.

<project> <modelVersion>4.0.0</modelVersion> <groupId>org.sonatype.mavenbook</groupId> <artifactId>my-project</artifactId> <version>1.0</version></project>

Das ist alles, was Sie in Ihrer pom.xml brauchen. Die Ausführung von mvn install über die Befehlszeile verarbeitet Ressourcen, kompiliert den Quellcode, führt Unittests aus, erstellt ein JAR und installiert das JAR in einem lokalen Repository zur Wiederverwendung in anderen Projekten. Ohne Modifikation können Sie mvn site ausführen und finden dann in target/site eine index.html-Datei vor, die Links zu JavaDoc und einige Berichte über Ihren Quellcode enthält.

Zugegeben, dies ist das einfachste mögliche Beispielprojekt, das nicht mehr als etwas Quellcode enthält und ein einfaches JAR erzeugt. Es ist ein Projekt, das sich eng an die Maven-Konventionen hält und keine Abhängigkeiten oder Anpassungen erfordert. Wenn wir anfangen wollen, das Verhalten anzupassen, wird unsere pom.xml immer größer, und in den größten Projekten können Sie Sammlungen von sehr komplexen Maven POMs sehen, die eine große Menge an Plugin-Anpassungen und Abhängigkeitserklärungen enthalten. Aber selbst wenn die POM-Dateien Ihres Projekts umfangreicher werden, enthalten sie eine völlig andere Art von Informationen als die Build-Datei eines ähnlich großen Projekts mit Ant. Maven POMs enthalten Deklarationen: „Dies ist ein JAR-Projekt“ und „Der Quellcode befindet sich in src/main/java“. Ant-Build-Dateien enthalten explizite Anweisungen: „Dies ist ein Projekt“, „Der Quellcode befindet sich in src/main/java“, „Führe javac gegen dieses Verzeichnis aus“, „Lege die Ergebnisse in target/classes ab“, „Erstelle ein JAR aus ….“ usw. Während Ant den Prozess explizit beschreiben musste, war in Maven etwas „eingebaut“, das einfach wusste, wo sich der Quellcode befand und wie er verarbeitet werden sollte.

Die Unterschiede zwischen Ant und Maven in diesem Beispiel sind:

Maven verfügt über eingebaute Intelligenz über allgemeine Projektaufgaben in Form von Maven Plugins. Wenn Sie Unit-Tests schreiben und ausführen möchten, müssen Sie nur die Tests schreiben, sie in${basedir}/src/test/java ablegen, eine testspezifische Abhängigkeit von TestNG oder JUnit hinzufügen und mvn test ausführen. Wenn Sie eine Webanwendung und keine JAR-Datei bereitstellen möchten, müssen Sie lediglich den Projekttyp in war ändern und Ihr Docroot in${basedir}/src/main/webapp ablegen. Natürlich können Sie das alles auch mitAnt machen, aber dann müssen Sie die Anweisungen von Grund auf neu schreiben. In Ant müssten Sie zunächst herausfinden, wo die JUnit-JAR-Datei sein soll. Dann müssen Sie einen Klassenpfad erstellen, der die JUnit-JAR-Datei enthält. Dann würden Sie Ant mitteilen, wo es nach Test-Quellcode suchen soll, ein Goal schreiben, das den Test-Quellcode in Bytecode kompiliert, und die Unit-Tests mit JUnit ausführen.

Ohne unterstützende Technologien wie Antlibs und Ivy (selbst mit diesen unterstützenden Technologien), hat Ant das Gefühl eines benutzerdefinierten prozeduralen Builds. Ein effizienter Satz von Maven POMs in einem Projekt, das sich an die von Maven angenommenen Konventionen hält, hat im Vergleich zur Ant-Alternative erstaunlich wenig XML. Ein weiterer Vorteil von Maven ist das Vertrauen in die weit verbreiteten Maven Plugins. Jeder benutzt das Maven Surefire Plugin für Unit-Tests, und wenn jemand Unterstützung für ein neues Unit-Testing-Framework hinzufügt, können Sie neue Fähigkeiten in Ihrem eigenen Build erhalten, indem Sie einfach die Version eines bestimmten Maven Plugins in der POM Ihres Projekts erhöhen.

Die Entscheidung, Maven oder Ant zu benutzen, ist keine binäre Entscheidung, und Ant hat immer noch einen Platz in einem komplexen Build. Wenn Ihr aktueller Build einen hochgradig angepassten Prozess enthält, oder wenn Sie einige Ant-Skripte geschrieben haben, um einen bestimmten Prozess auf eine bestimmte Art und Weise abzuschließen, die nicht an die Maven-Standards angepasst werden kann, können Sie diese Skripte immer noch mit Maven verwenden. Ant wird als ein Kern-Maven-Plugin zur Verfügung gestellt. Benutzerdefinierte Maven-Plugins können in Ant implementiert werden, und Maven-Projekte können so konfiguriert werden, dass Ant-Skripte innerhalb des Maven-Projektlebenszyklus ausgeführt werden.