Ce site met a disposition le build journalier de la traduction francaise du Maven: The Definitive Guide
Consultez :
  • Les documents de reference sur le projet original
  • Les sources de la traduction fr sur GitHub
  • maven


    1.7. Comparaison de Maven et de Ant

    Les auteurs de ce livre n'ont pas pour objectif de créer de l'animosité entre Apache Ant et Apache Maven. Cependant nous sommes conscients que, pour la plupart des organisations, il faut faire un choix entre Apache Ant et Apache Maven. Dans cette section, nous allons comparer ces deux outils.

    Ant excelle dans le processus de build, c'est un système de build héritant de make avec des cibles et des dépendances. Chaque cible se compose d'un ensemble d'instructions codées en XML. Il existe une tâche copy, une tâche javac, tout comme une tâche jar. Quand vous utilisez Ant, vous lui fournissez un ensemble d'instructions spécifiques pour compiler et packager le résultat. Prenons par exemple ce simple fichier build.xml :

    Exemple 1.1. Simple fichier build.xml pour Ant

    <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, on peut voir qu'il faut dire à Ant exactement ce qu’il doit faire. On a une cible compile qui inclut la tâche javac pour compiler le code source du répertoire src/main/java dans le répertoire target/classes. Vous devez indiquer à Ant exactement où se trouve votre code source, où le bytecode produit devra être sauvé, et comment packager tout cela dans un fichier JAR. Même si des développements récents tendent à rendre Ant moins procédural, pour un développeur, Ant reste un langage de code procédural en XML.

    Comparons l'exemple Ant précédent avec un exemple Maven. Avec Maven, pour créer un fichier JAR à partir de code source Java, tout ce que vous avez à faire est de créer un simple fichier pom.xml, mettre votre code source dans ${basedir}/src/main/java et exécuter la commande mvn install depuis la ligne de commande. Le contenu du fichier pom.xml Maven qui permet d'obtenir le même résultat que le simple fichier Ant décrit dans l'Exemple 1.1, « Simple fichier build.xml pour Ant » est le suivant :

    Exemple 1.2. Simple fichier pom.xml pour Maven

    <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. Exécuter mvn install depuis la ligne de commande va traiter les ressources, compiler le source, exécuter les tests unitaires, créer un JAR, et installer ce JAR dans le dépôt local pour qu'il soit réutilisable par d'autres projets. Toujours sans rien modifier, vous pouvez exécuter la commande mvn site et vous trouverez un fichier index.html dans target/site contenant des liens vers la JavaDoc et quelques rapports sur votre code source.

    Certes, c'est l'exemple de projet le plus simple possible. Il ne contient rien d'autre que du code source et produit un JAR. C'est un projet qui suit les conventions de Maven et qui ne demande aucune dépendance ou personnalisation. Si nous voulons personnaliser le comportement, notre fichier pom.xml va grossir, et dans les plus gros projets, vous pouvez trouver une collection de POMs Maven très complexes qui contiennent beaucoup de configuration de plugins et de déclarations de dépendances. Mais, même lorsque les fichiers POM de votre projet grossissent, ils contiennent des informations d'une nature différente de celles du fichier de build Ant d'un projet de taille similaire. Les POMs Maven contiennent des déclarations : "C'est un projet JAR" ou "Le code source se trouve dans src/main/java". Les scripts Ant contiennent des instructions explicites : "Ceci est le projet", "Le code source se trouve dans src/main/java", "Exécuter javac sur ce répertoire, "Mettre les résultats dans target/classes", "Créer un JAR à partir de ....", etc. Là où Ant se doit d'être explicite avec le traitement, il y a quelque chose "d'inné" chez Maven qui sait où se trouve le code source et ce qu'il doit en faire.

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

    Apache Ant
    • Ant ne dispose d'aucune convention formelle ni comportement par défaut. Il vous faut indiquer à Ant exactement où trouver le source et où mettre les résultats. Des conventions informelles ont émergé au cours du temps, mais elles n'ont pas été intégrées au produit.

    • Ant est procédural. Il faut lui indiquer exactement ce qu'il doit faire et quand le faire. Il faut lui dire de compiler, puis de copier, puis de compresser.

    • Ant n'a pas de cycle de vie. Vous devez définir des fonctions et les dépendances de ces fonctions. Vous devez ensuite rattacher une série de tâches à chaque fonction manuellement.

    Apache Maven
    • Maven possède ses conventions. Il sait où se trouve le code source car vous suivez une convention. Le plugin Maven Compiler place le bytecode dans target/classes et produit un fichier JAR dans le répertoire target.

    • Maven est déclaratif. Tout ce que vous avez à faire est de créer un fichier pom.xml et mettre votre code source dans le répertoire par défaut. Maven s'occupe du reste.

    • Maven possède son propre cycle de vie que vous invoquez lorsque vous exécutez la commande mvn install. Cette commande demande à Maven d'exécuter une série d'étapes jusqu'à la fin du cycle de vie. Une des conséquences de ce parcours du cycle de vie, est que Maven exécute un certain nombre de goals de plugins par défaut qui vont réaliser certaines tâches comme de compiler et de créer un JAR.

    Maven intègre une certaine intelligence sur les tâches communes sous la forme de plugins Maven. Si vous voulez écrire et exécuter des tests unitaires, tout ce que vous avez à faire est d'écrire ces tests et de les mettre dans ${basedir}/src/test/java, ajouter une dépendance de type test sur TestNG ou JUnit, et exécuter la commande mvn test. Si vous voulez déployer une application web et non plus un JAR, tout ce que vous avez à faire est de changer le type de votre projet en war et de positionner le répertoire racine de l'application web sur ${basedir}/src/main/webapp. Bien sûr, vous pourriez faire tout cela avec Ant mais vous devriez tout écrire depuis le début. Dans Ant, vous devriez commencer par définir où devrait se trouver le fichier JAR de JUnit, ensuite vous devriez créer un classpath qui contienne ce fichier JAR de JUnit, puis vous devriez indiquer à Ant où devrait se trouver le code source des tests, écrire une fonction pour compiler le code source des tests en bytecode, et pour exécuter ces tests unitaires avec JUnit.

    Sans l'apport des technologies comme antlibs et Ivy (et même avec ces technologies complémentaires), Ant laisse l'impression d'un build procédural personnalisé. Un ensemble efficace de POMs Maven dans un projet qui respecte les conventions de Maven a peu de XML, aussi surprenant que cela puisse paraître, en comparaison de Ant. Un autre avantage de Maven est qu'il s'appuie sur des plugins Maven très largement diffusés et partagés. Tout le monde utilise le plugin Maven Surefire pour les tests unitaires, et si quelqu'un ajoute le support d'un nouveau framework de tests unitaires, vous obtenez cette nouvelle fonctionnalité dans votre build juste en incrémentant le numéro de version de ce plugin particulier dans le POM de votre projet.

    La décision d'utiliser Maven ou Ant n'est pas une décision binaire, et Ant a toujours sa place pour les builds complexes. Si votre build contient un traitement très spécifique, ou si vous avez écrit des scripts Ant pour remplir une tâche particulière de manière spécifique qui ne peut être adaptée aux standards Maven, vous pouvez toujours utiliser ces scripts dans Maven. Ant est disponible sous la forme d'un des principaux plugins de Maven. Des plugins personnalisés de Maven peuvent être écrits en utilisant Ant, et les projets Maven peuvent être configurés pour exécuter des scripts Ant durant le cycle de vie du projet Maven.