Différences entre Ant et Maven [fermé]

Quelqu'un pourrait-il me dire les différences entre Ant et Maven? Je ne l'ai jamais utilisé non plus. Je comprends qu'ils sont utilisés pour automatiser la construction de projets Java, mais je ne sais pas par où commencer.

Dans Maven: The Definitive Guide , j'ai écrit sur les différences entre Maven et Ant dans l'introduction, le titre de la section est "Les différences entre Ant et Maven" . Voici une réponse qui combine les informations de cette introduction avec quelques notes supplémentaires.

Une simple comparaison

Je ne vous montre cela que pour illustrer l'idée que, au niveau le plus élémentaire, Maven a des conventions intégrées. Voici un simple fichier de construction 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 simple de Ant, vous pouvez voir comment vous devez dire exactement à Ant ce qu'il doit faire. Il existe un objectif de compilation qui inclut la tâche javac qui compile la source dans le répertoire src / main / java vers le répertoire target / classes. Vous devez indiquer à Ant exactement où se trouve votre source, où vous voulez que le bytecode résultant soit stocké, et comment le regrouper dans un fichier JAR. Bien que certains développements récents contribuent à rendre Ant moins procédural, l'expérience d'un développeur avec Ant consiste à coder un langage procédural écrit en XML.

Comparez le précédent exemple Ant avec un exemple Maven. Dans Maven, pour créer un fichier JAR à partir d'une source Java, tout ce que vous avez à faire est 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 Maven pom.xml qui permet d'obtenir les mêmes résultats.

<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 la source, exécutera des tests unitaires, créera un JAR et installera le JAR dans un référentiel local pour une réutilisation dans d'autres projets. Sans modification, vous pouvez exécuter mvn site, puis trouver un fichier index.html dans target / site qui contient des liens vers JavaDoc et quelques rapports sur votre code source.

Certes, c'est l'exemple de projet le plus simple possible. Un projet qui ne contient que du code source et qui produit un JAR. Un projet qui suit les conventions Maven et ne nécessite aucune dépendance ni personnalisation. Si nous voulions commencer à personnaliser le comportement, notre pom.xml va grossir, et dans le plus grand des projets, vous pouvez voir des collections de POM Maven très complexes qui contiennent beaucoup de personnalisation de plugins et de déclarations de dépendance. Mais, même lorsque les fichiers POM de votre projet deviennent plus volumineux, ils contiennent un type d'informations totalement différent du fichier de construction d'un projet de taille similaire utilisant Ant. Les POM Maven contiennent des déclarations: "Ceci est un projet JAR" et "Le code source est dans src / main / java". Les fichiers de construction Ant contiennent des instructions explicites: "Ceci est un projet", "src/main/java"," Exécuter javacsur ce répertoire "," Mettre les résultats dans target/classses"," Créer un JAR à partir du .... ", etc. Là où Ant devait être explicite sur le processus, il y avait quelque chose" intégré "à Maven qui savait juste où se trouvait le code source et comment il devait être traité.

Comparaison de haut niveau

Les différences entre Ant et Maven dans cet exemple? Fourmi...

• n'a pas de conventions formelles comme une structure de répertoire de projet commune, vous devez dire à Ant exactement où trouver la source et où placer la sortie. Des conventions informelles sont apparues au fil du temps, mais elles n'ont pas été codifiées dans le produit.
• est procédural, vous devez dire à Ant exactement quoi faire et quand le faire. Il fallait lui dire de compiler, puis de copier, puis de compresser.
• n'a pas de cycle de vie, vous deviez définir des objectifs et des dépendances d'objectifs. Vous deviez associer manuellement une séquence de tâches à chaque objectif.

Où Maven ...

• a des conventions, il savait déjà où se trouvait votre code source car vous avez suivi la convention. Il a mis le bytecode dans target / classes, et il a produit un fichier JAR dans target.
• est déclaratif. Tout ce que vous aviez à faire était de créer un fichier pom.xml et de placer votre source dans le répertoire par défaut. Maven s'est occupé du reste.
• a un cycle de vie, que vous avez appelé lors de l'exécution mvn install. Cette commande a dit à Maven d'exécuter une série d'étapes de séquence jusqu'à ce qu'il atteigne le cycle de vie. En tant qu'effet secondaire de ce voyage à travers le cycle de vie, Maven a exécuté un certain nombre d'objectifs de plugin par défaut qui ont fait des choses comme compiler et créer un JAR.

Et Ivy?

Bien, donc quelqu'un comme Steve Loughran va lire cette comparaison et appeler faute. Il va parler de la façon dont la réponse ignore complètement quelque chose appelé Ivy et du fait qu'Ant peut réutiliser la logique de construction dans les versions les plus récentes d'Ant. C'est vrai. Si vous avez un groupe de personnes intelligentes qui utilisent Ant + antlibs + Ivy, vous vous retrouverez avec une version bien conçue qui fonctionne. Même si je suis très convaincu que Maven a du sens, j'utiliserais volontiers Ant + Ivy avec une équipe de projet qui avait un ingénieur de construction très pointu. Cela étant dit, je pense que vous finirez par manquer un certain nombre de plugins précieux tels que le plugin Jetty et que vous finirez par faire tout un travail que vous n'avez pas eu besoin de faire au fil du temps.

Plus important que Maven vs Ant

1. Est-ce que vous utilisez un Repository Manager pour garder une trace des artefacts logiciels. Je suggère de télécharger Nexus . Vous pouvez utiliser Nexus pour proxy des référentiels distants et pour fournir à votre équipe un endroit pour déployer des artefacts internes.
2. Vous disposez d'une modularisation appropriée des composants logiciels. Un gros composant monolithique évolue rarement avec le temps. Au fur et à mesure que votre projet se développe, vous voudrez avoir le concept de modules et de sous-modules. Maven se prête très bien à cette approche.
3. Vous adoptez certaines conventions pour votre build. Même si vous utilisez Ant, vous devez vous efforcer d'adopter une forme de convention cohérente avec d'autres projets. Lorsqu'un projet utilise Maven, cela signifie que toute personne familière avec Maven peut prendre la compilation et commencer à l'exécuter sans avoir à manipuler la configuration juste pour savoir comment obtenir la compilation.

Maven est un framework, Ant est une boîte à outils

Maven est une voiture de route pré-construite, tandis que Ant est un ensemble de pièces automobiles. Avec Ant, vous devez construire votre propre voiture, mais au moins si vous devez faire de la conduite hors route, vous pouvez construire le bon type de voiture.

Pour le dire autrement, Maven est un framework alors que Ant est une boîte à outils. Si vous vous contentez de travailler dans les limites du cadre, Maven fera très bien l'affaire. Le problème pour moi était que je continuais à me heurter aux limites du cadre et qu'il ne me laissait pas sortir.

Verbosité XML

tobrien est un gars qui en sait beaucoup sur Maven et je pense qu'il a fourni une très bonne comparaison honnête des deux produits. Il a comparé un simple Maven pom.xml avec un simple fichier de construction Ant et il a mentionné comment les projets Maven peuvent devenir plus complexes. Je pense que cela vaut la peine de jeter un coup d'œil à une comparaison de quelques fichiers que vous êtes plus susceptible de voir dans un simple projet du monde réel. Les fichiers ci-dessous représentent un seul module dans une construction multi-module.

Tout d'abord, le fichier Maven:

<project 
    xmlns="http://maven.apache.org/POM/4.0.0" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-4_0_0.xsd">

    <parent>
        <groupId>com.mycompany</groupId>
        <artifactId>app-parent</artifactId>
        <version>1.0</version>
    </parent>

    <modelVersion>4.0.0</modelVersion>
    <artifactId>persist</artifactId>
    <name>Persistence Layer</name>

    <dependencies>

        <dependency>
            <groupId>com.mycompany</groupId>
            <artifactId>common</artifactId>
            <scope>compile</scope>
            <version>${project.version}</version>
        </dependency>

        <dependency>
            <groupId>com.mycompany</groupId>
            <artifactId>domain</artifactId>
            <scope>provided</scope>
            <version>${project.version}</version>
        </dependency>

        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate</artifactId>
            <version>${hibernate.version}</version>
            <scope>provided</scope>
        </dependency>

        <dependency>
            <groupId>commons-lang</groupId>
            <artifactId>commons-lang</artifactId>
            <version>${commons-lang.version}</version>
            <scope>provided</scope>
        </dependency>

        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring</artifactId>
            <version>${spring.version}</version>
            <scope>provided</scope>
        </dependency>

        <dependency>
            <groupId>org.dbunit</groupId>
            <artifactId>dbunit</artifactId>
            <version>2.2.3</version>
            <scope>test</scope>
        </dependency>

        <dependency>
            <groupId>org.testng</groupId>
            <artifactId>testng</artifactId>
            <version>${testng.version}</version>
            <scope>test</scope>
            <classifier>jdk15</classifier>
        </dependency>

        <dependency>
            <groupId>commons-dbcp</groupId>
            <artifactId>commons-dbcp</artifactId>
            <version>${commons-dbcp.version}</version>
            <scope>test</scope>
        </dependency>

        <dependency>
            <groupId>com.oracle</groupId>
            <artifactId>ojdbc</artifactId>
            <version>${oracle-jdbc.version}</version>
            <scope>test</scope>
        </dependency>

        <dependency>
            <groupId>org.easymock</groupId>
            <artifactId>easymock</artifactId>
            <version>${easymock.version}</version>
            <scope>test</scope>
        </dependency>

    </dependencies>

</project>

Et le fichier Ant équivalent:

<project name="persist" >

    <import file="../build/common-build.xml" />


    <path id="compile.classpath.main">
        <pathelement location="${common.jar}" />
        <pathelement location="${domain.jar}" />
        <pathelement location="${hibernate.jar}" />
        <pathelement location="${commons-lang.jar}" />
        <pathelement location="${spring.jar}" />
    </path>


    <path id="compile.classpath.test">
        <pathelement location="${classes.dir.main}" />
        <pathelement location="${testng.jar}" />
        <pathelement location="${dbunit.jar}" />
        <pathelement location="${easymock.jar}" />
        <pathelement location="${commons-dbcp.jar}" />
        <pathelement location="${oracle-jdbc.jar}" />
        <path refid="compile.classpath.main" />
    </path>


    <path id="runtime.classpath.test">
        <pathelement location="${classes.dir.test}" />
        <path refid="compile.classpath.test" />
    </path>


</project>

tobrien a utilisé son exemple pour montrer que Maven a des conventions intégrées, mais cela ne signifie pas nécessairement que vous finissez par écrire moins de XML. J'ai trouvé le contraire vrai. Le pom.xml est 3 fois plus long que le build.xml et c'est sans s'écarter des conventions. En fait, mon exemple Maven est montré sans 54 lignes supplémentaires nécessaires pour configurer les plugins. Ce pom.xml est destiné à un projet simple. Le XML commence vraiment à se développer de manière significative lorsque vous commencez à ajouter des exigences supplémentaires, ce qui n'est pas inhabituel pour de nombreux projets.

Mais tu dois dire à Ant quoi faire

Mon exemple de fourmi ci-dessus n'est bien sûr pas complet. Nous devons encore définir les cibles utilisées pour nettoyer, compiler, tester, etc. Celles-ci sont définies dans un fichier de construction commun qui est importé par tous les modules du projet multi-module. Ce qui m'amène au point sur la façon dont tout cela doit être explicitement écrit dans Ant alors que c'est déclaratif dans Maven.

C'est vrai, cela me ferait gagner du temps si je n'avais pas à écrire explicitement ces cibles Ant. Mais combien de temps? Le fichier de construction commun que j'utilise maintenant est celui que j'ai écrit il y a 5 ans avec seulement de légères améliorations depuis lors. Après mes 2 ans d'expérience avec Maven, j'ai sorti l'ancien fichier de construction Ant du placard, l'ai dépoussiéré et remis au travail. Pour moi, le coût d'avoir à dire explicitement à Ant quoi faire s'est élevé à moins d'une semaine sur une période de 5 ans.

Complexité

La prochaine différence majeure que je voudrais mentionner est celle de la complexité et de l'effet réel qu'elle a. Maven a été conçu avec l'intention de réduire la charge de travail des développeurs chargés de créer et de gérer les processus de construction. Pour ce faire, il doit être complexe. Malheureusement, cette complexité a tendance à nier l'objectif visé.

Par rapport à Ant, le constructeur d'un projet Maven passera plus de temps:

• Lecture de la documentation: Il y a beaucoup plus de documentation sur Maven, car il y a tellement plus que vous devez apprendre.
• Éduquer les membres de l'équipe: ils trouvent plus facile de demander à quelqu'un qui sait que d'essayer de trouver des réponses eux-mêmes.
• Dépannage de la construction: Maven est moins fiable que Ant, en particulier les plugins non-core. De plus, les builds Maven ne sont pas répétables. Si vous dépendez d'une version SNAPSHOT d'un plugin, ce qui est très probable, votre build peut casser sans que vous n'ayez rien changé.
• Ecrire des plugins Maven: Les plugins sont généralement écrits avec une tâche spécifique à l'esprit, par exemple créer un bundle webstart, ce qui rend plus difficile leur réutilisation pour d'autres tâches ou leur combinaison pour atteindre un objectif. Il se peut donc que vous deviez écrire l'un des vôtres pour contourner les lacunes de l'ensemble de plugins existant.

En revanche:

• La documentation Ant est concise, complète et en un seul endroit.
• Ant est simple. Un nouveau développeur essayant d'apprendre Ant n'a besoin que de comprendre quelques concepts simples (cibles, tâches, dépendances, propriétés) pour pouvoir comprendre le reste de ce qu'il doit savoir.
• Ant est fiable. Il n'y a pas eu beaucoup de versions d'Ant ces dernières années car cela fonctionne déjà.
• Les builds Ant sont répétables car ils sont généralement créés sans aucune dépendance externe, telle que des référentiels en ligne, des plugins tiers expérimentaux, etc.
• Ant est complet. Comme il s'agit d'une boîte à outils, vous pouvez combiner les outils pour effectuer presque toutes les tâches que vous souhaitez. Si jamais vous avez besoin d'écrire votre propre tâche personnalisée, c'est très simple à faire.

Familiarité

Une autre différence est celle de la familiarité. Les nouveaux développeurs ont toujours besoin de temps pour se mettre à niveau. La connaissance des produits existants aide à cet égard et les partisans de Maven affirment à juste titre que c'est un avantage de Maven. Bien sûr, la flexibilité de Ant signifie que vous pouvez créer toutes les conventions que vous aimez. Donc, la convention que j'utilise est de mettre mes fichiers source dans un nom de répertoire src / main / java. Mes classes compilées vont dans un répertoire nommé target / classes. Cela semble familier n'est-ce pas.

J'aime la structure de répertoires utilisée par Maven. Je pense que cela a du sens. Aussi leur cycle de vie de construction. J'utilise donc les mêmes conventions dans mes builds Ant. Non seulement parce que cela a du sens, mais parce qu'il sera familier à quiconque a déjà utilisé Maven.

Ant est principalement un outil de construction.

Maven est un outil de gestion de projet et de dépendances (qui bien sûr construit également votre projet).

Ant + Ivy est une très bonne combinaison si vous voulez éviter Maven.

Juste pour énumérer quelques différences supplémentaires:

• Ant n'a pas de conventions formelles. Vous devez dire à Ant exactement où trouver la source, où mettre les sorties, etc.
• Ant est procédurale. Vous devez dire exactement à Ant ce qu'il doit faire; dites-lui de compiler, copier, puis compresser, etc.
• Ant n'a pas de cycle de vie.
• Maven utilise des conventions. Il sait automatiquement où se trouve votre code source, tant que vous suivez ces conventions. Vous n'avez pas besoin de dire à Maven où il se trouve.
• Maven est déclaratif; Tout ce que vous avez à faire est de créer un fichier pom.xml et de placer votre source dans le répertoire par défaut. Maven s'occupera du reste.
• Maven a un cycle de vie. Vous appelez simplement mvn install et une série d'étapes de séquence sont exécutées.
• Maven a des informations sur les tâches courantes du projet. Pour exécuter des tests, exécutez simplement mvn test , tant que les fichiers sont dans l'emplacement par défaut. Dans Ant, vous devez d'abord créer le fichier JAR JUnit, puis créer un chemin de classe qui inclut le JAR JUnit, puis indiquer à Ant où il doit rechercher le code source du test, écrire un objectif qui compile la source du test, puis enfin exécuter les tests unitaires. avec JUnit.

Mise à jour:

Cela vient de Maven: The Definitive Guide . Désolé, j'ai totalement oublié de le citer.

Maven ou Ant? est une question très similaire à celle-ci, qui devrait vous aider à répondre à vos questions.

Qu'est-ce que Maven? sur le site officiel.

edit: Pour un nouveau projet / greenfield, je vous recommande d'utiliser Maven: "convention sur la configuration" vous fera gagner un temps décent dans l'écriture et la mise en place des scripts de construction et de déploiement. Lorsque vous utilisez ant, le script de construction a tendance à augmenter avec le temps en longueur et en complexité. Pour les projets existants, il peut être difficile d'intégrer leur configuration / disposition dans le système Maven.

Maven agit à la fois comme un outil de gestion des dépendances - il peut être utilisé pour récupérer des fichiers JAR à partir d'un référentiel central ou d'un référentiel que vous avez configuré - et comme un outil de construction déclaratif. La différence entre un outil de construction "déclaratif" et un outil plus traditionnel comme ant ou make est que vous configurez ce qui doit être fait, pas comment cela se fait. Par exemple, vous pouvez dire dans un script maven qu'un projet doit être empaqueté en tant que fichier WAR, et maven sait comment gérer cela.

Maven s'appuie sur des conventions sur la façon dont les répertoires de projet sont disposés afin d'atteindre son «caractère déclaratif». Par exemple, il a une convention pour savoir où mettre votre code principal, où mettre votre web.xml, vos tests unitaires, etc., mais donne également la possibilité de les modifier si vous en avez besoin.

Vous devez également garder à l'esprit qu'il existe un plugin pour exécuter des commandes ant à partir de maven:

http://maven.apache.org/plugins/maven-ant-plugin/

De plus, les archétypes de maven permettent de démarrer un projet très rapidement. Par exemple, il existe un archétype Wicket, qui fournit une commande maven que vous exécutez pour obtenir un projet de type mondial Hello prêt à l'emploi.

https://wicket.apache.org/start/quickstart.html

Je peux prendre une personne qui n'a jamais vu Ant - ses build.xmls sont raisonnablement bien écrits - et ils peuvent comprendre ce qui se passe. Je peux prendre cette même personne et leur montrer un Maven POM et ils n'auront aucune idée de ce qui se passe.

Dans une organisation d'ingénierie énorme, les gens écrivent sur le fait que les fichiers Ant deviennent volumineux et ingérables. J'ai écrit ces types et nettoyé les scripts Ant. Il s'agit vraiment de comprendre dès le départ ce que vous devez faire à l'avenir et de concevoir un ensemble de modèles qui peuvent répondre au changement et évoluer sur une période de plus de 3 ans.

À moins que vous n'ayez un projet simple, apprendre les conventions Maven et la méthode Maven pour faire avancer les choses est un peu de travail.

En fin de compte, vous ne pouvez pas considérer le démarrage de projet avec Ant ou Maven comme un facteur: c'est vraiment le coût total de possession. Ce qu'il faut à l'organisation pour maintenir et étendre son système de build sur quelques années est l'un des principaux facteurs à prendre en compte.

Les aspects les plus importants d'un système de build sont la gestion des dépendances et la flexibilité dans l'expression de la recette de build. Il doit être quelque peu intuitif lorsqu'il est bien fait.

Je dirais que cela dépend de la taille de votre projet ... Personnellement, j'utiliserais Maven pour des projets simples qui nécessitent une compilation, un packaging et un déploiement simples. Dès que vous avez besoin de faire des choses plus compliquées (nombreuses dépendances, création de fichiers de mappage ...), je passerais à Ant ...

Maven abrite également un vaste référentiel de projets open source couramment utilisés. Pendant la construction, Maven peut télécharger ces dépendances pour vous (ainsi que vos dépendances :)) pour rendre cette partie de la construction d'un projet un peu plus gérable.