TheNEXUS

Les auteurs de ce livre n’ont aucun intérêt à créer une querelle entreApache Ant et Apache Maven, mais nous sommes également conscients du fait que la plupart des organisations doivent prendre une décision entre les deux solutions standard : Apache Ant et Apache Maven. Dans cette section, nous comparons et opposons les outils.

Ant excelle dans le processus de construction, c’est un système de construction modelé sur make avec des cibles et des dépendances. Chaque cible consiste en un ensemble d’instructions qui sont codées en XML. Il existe une tâche copy et une tâchejavac ainsi qu’une tâche jar. Lorsque vous utilisez Ant, vous lui fournissez des instructions spécifiques pour compiler et empaqueter vos résultats. Regardez l’exemple suivant d’un fichier build.xml simple:

Un fichier build.xml Ant simple.

<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>

Dans cet exemple Ant simple, vous pouvez voir comment vous devez dire à Antexactly ce qu’il faut faire. Il y a un objectif de compilation qui inclut la javactâche qui compile la source dans le répertoire src/main/java vers le répertoiretarget/classes. Vous devez dire à Ant exactement où se trouve votre source, où vous voulez que le bytecode résultant soit stocké, et comment empaqueter tout cela dans un fichier JAR. Bien qu’il y ait quelques développements récents qui aident à rendre Ant moins procédural, l’expérience sexuelle d’un développeur avec Ant consiste à coder un langage procédural écrit en XML.

Contrastez l’exemple Ant précédent avec un exemple Maven. Dans Maven, pour créer un fichier JAR à partir d’une source Java quelconque, il suffit de créer un simple pom.xml, de placer votre code source dans${basedir}/src/main/java, puis d’exécuter mvn install à partir de la ligne de commande. L’exemple de pom.xml Maven qui permet d’obtenir les mêmes résultats que le fichier Ant simple répertorié dans A Simple Ant build.xml file est présenté dansA Sample Maven pom.xml.

A Sample Maven pom.xml.

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

C’est tout ce dont vous avez besoin dans votre pom.xml. L’exécution de mvn install à partir de la ligne de commande traitera les ressources, compilera les sources, exécutera les unittests, créera un JAR et installera le JAR dans un dépôt local pour le réutiliser dans d’autres projets. Sans modification, vous pouvez exécuter mvn siteet ensuite trouver un fichier index.html dans target/site qui contient des liens vers JavaDoc et quelques rapports sur votre code source.

Avouez que c’est le projet d’exemple le plus simple possible ne contenant rien de plus qu’un peu de code source et produisant un JAR simple. C’est un projet qui suit de près les conventions Maven et qui ne nécessite aucune dépendance ou personnalisation. Si nous voulons commencer à personnaliser le comportement, notre pom.xml va devenir de plus en plus volumineux, et dans les projets les plus importants, vous pouvez voir des collections de POM Maven très complexes qui contiennent une grande quantité de personnalisation de plugins et de déclarations de dépendances. Mais, même lorsque les fichiers POM de votre projet deviennent plus substantiels, ils contiennent un type d’information entièrement différent du fichier de construction d’un projet de taille similaire utilisant Ant. Les POMs Maven contiennent des déclarations : « Ceci est un projet JAR », et « Le code source se trouve dans src/main/java ». Les fichiers de construction Ant contiennent des instructions explicites : « Ceci est un projet », « Le code source se trouve dans src/main/java », « Exécuter javacag contre ce répertoire », « Mettre les résultats dans target/classes », « Créer un JAR à partir de …. », etc. Là où Ant devait être explicite sur le processus, il y avait quelque chose d' »intégré » à Maven qui savait simplement où était le code source et comment il devait être traité.

Les différences entre Ant et Maven dans cet exemple sont :

Maven a une intelligence intégrée sur les tâches communes du projet sous la forme de plugins Maven. Si vous voulez écrire et exécuter des tests unitaires, il vous suffit d’écrire les tests, de les placer dans${basedir}/src/test/java, d’ajouter une dépendance de test soit TestNG, soit JUnit, et d’exécuter mvn test. Si vous vouliez déployer une application web et non un JAR, tout ce que vous auriez à faire serait de changer votre type de projet en war et de placer votre docroot dans${basedir}/src/main/webapp. Bien sûr, vous pouvez faire tout cela avecAnt, mais vous devrez écrire les instructions à partir de zéro. Dans Ant, vous devrez d’abord déterminer où se trouve le fichier JAR de JUnit. Ensuite, vous devez créer un classpath qui inclut le fichier JUnit JAR. Ensuite, vous diriez à Ant où il devrait chercher le code source de test, écrire un objectif qui compile le source de test en bytecode, etexécuter les tests unitaires avec JUnit.

Sans technologies de support comme antlibs et Ivy (même avec ces technologies de support), Ant a le sentiment d’un c`ustom proceduralbuild. Un ensemble efficace de POMs Maven dans un projet qui adhère aux conventions supposées de Maven a étonnamment peu de XML comparé à l’alternative Ant. Un autre avantage de Maven est le recours à des plugins Maven largement partagés. Tout le monde utilise le plugin Maven Surefire pour les tests unitaires, et si quelqu’un ajoute le support d’un nouveau cadre de tests unitaires, vous pouvez obtenir de nouvelles capacités dans votre propre build en augmentant simplement la version d’un plugin Maven particulier dans le POM de votre projet.

La décision d’utiliser Maven ou Ant n’est pas binaire, et Ant a toujours une place dans un build complexe. Si votre build actuel contient un processus hautement personnalisé, ou si vous avez écrit quelques scripts Ant pour compléter un processus spécifique d’une manière spécifique qui ne peut pas être adapté aux standardsMaven, vous pouvez toujours utiliser ces scripts avec Maven. Ant est disponible en tant que plugin Maven de base. Les plugins Maven personnalisés peuvent êtreimplémentés dans Ant, et les projets Maven peuvent être configurés pour exécuter des scriptsAnt dans le cycle de vie du projet Maven.