Différences entre Ant et Maven

Question

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

Answer 1

Dans Maven: Le Guide Définitif, j'ai écrit sur les différences entre Maven et Ant dans l'introduction dont 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 Comparaison Simple

Je vous montre ceci uniquement pour illustrer l'idée que, au niveau le plus basique, Maven a des conventions intégrées. Voici un simple fichier de construction Ant :

        exemple de fichier de construction simple

Dans cet exemple Ant simple, vous pouvez voir comment vous devez dire exactement à Ant quoi faire. Il y a un objectif de compilation qui inclut la tâche javac qui compile la source du répertoire src/main/java dans le répertoire target/classes. Vous devez dire exactement à Ant où se trouve votre source, où vous voulez que le bytecode résultant soit stocké, et comment empaqueter tout cela dans un fichier JAR. Alors qu'il y a eu quelques développements récents pour rendre Ant moins procédural, l'expérience d'un développeur avec Ant est de coder dans 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 de certaines sources Java, tout ce que vous avez à faire est de créer un simple pom.xml, placer votre code source dans ${basedir}/src/main/java puis exécuter mvn install depuis la ligne de commande. Voici le pom.xml Maven exemple qui atteint les mêmes résultats.

  4.0.0
  org.sonatype.mavenbook
  mon-projet
  1.0

C'est tout ce dont vous avez besoin dans votre pom.xml. Exécuter mvn install depuis la ligne de commande traitera les ressources, compilera les sources, 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 et ensuite trouver un fichier index.html dans target/site qui contient des liens vers JavaDoc et quelques rapports sur votre code source.

Admettons, c'est le 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 de Maven et ne nécessite aucune dépendance ou personnalisation. Si nous voulions commencer à personnaliser le comportement, notre pom.xml va augmenter en taille, et dans les plus grands des projets, vous pouvez voir des collections de POMs Maven très complexes qui contiennent beaucoup de personnalisation de plugins et de déclarations de dépendances. Mais, même lorsque les fichiers POM de votre projet deviennent plus importants, ils contiennent un tout autre type d'informations que le fichier de construction d'un projet de taille similaire utilisant Ant. Les POMs Maven contiennent des déclarations : "C'est un projet JAR", et "Le code source est dans src/main/java". Les fichiers de construction Ant contiennent des instructions explicites : "C'est un projet", "La source est dans src/main/java", "Exécuter javac sur ce répertoire", "Mettre les résultats dans target/classses", "Créer un JAR à partir de ....", etc. Là où Ant devait être explicite sur le processus, il y avait quelque chose de "intégré" à Maven qui savait simplement où se trouvait le code source et comment il devait être traité.

Comparaison Haut Niveau

...

Answer 2

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

Maven est une voiture pré-construite, alors que Ant est un ensemble de pièces détachées. Avec Ant, vous devez construire votre propre voiture, mais au moins, si vous devez faire du tout-terrain, vous pouvez construire le bon type de voiture.

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

Verbosité XML

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

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 que cela ne signifie pas nécessairement que l'on finit par écrire moins de XML. J'ai constaté que c'est le contraire qui est vrai. Le pom.xml est 3 fois plus long que le build.xml et ce, sans s'écarter des conventions. En fait, mon exemple Maven est présenté sans les 54 lignes supplémentaires qui étaient nécessaires pour configurer les plugins. Ce pom.xml est pour un projet simple. Le XML commence vraiment à grossir de manière significative lorsque vous commencez à ajouter des exigences supplémentaires, ce qui n'est pas hors du commun pour de nombreux projets.

Mais tu dois dire à Ant ce qu'il doit 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 dans le projet multi-module. Ce qui m'amène à la question de savoir comment tous ces éléments doivent être explicitement écrits dans Ant alors qu'ils sont déclaratifs 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 compilation que j'utilise actuellement est un fichier que j'ai écrit il y a 5 ans et que j'ai légèrement amélioré depuis. Après mon expérience de deux ans avec Maven, j'ai ressorti le vieux fichier de construction Ant du placard, l'ai dépoussiéré et l'ai remis au travail. Pour moi, le coût de devoir dire explicitement à Ant ce qu'il doit faire s'est élevé à moins d'une semaine sur une période de 5 ans.

Complexité

La prochaine différence majeure que j'aimerais mentionner est celle de la complexité et de son effet dans le monde réel. Maven a été conçu dans le but 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é tend à annuler l'objectif visé.

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

• Documentation de lecture : Il y a beaucoup plus de documentation sur Maven, car il y a beaucoup plus à apprendre.
• Former les membres de l'équipe : Ils trouvent plus facile de demander à quelqu'un qui sait plutôt 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 essentiels. 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 se casser sans que vous ayez changé quoi que ce soit.
• Écriture de plugins Maven : Les plugins sont généralement écrits avec une tâche spécifique en tête, 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 votre propre plugin pour combler les lacunes de l'ensemble des plugins existants.

En revanche :

• La documentation sur les fourmis est concise, complète et regroupée en un seul endroit.
• Ant est simple. Un nouveau développeur essayant d'apprendre Ant n'a besoin de comprendre que quelques concepts simples (cibles, tâches, dépendances, propriétés) afin d'être capable de comprendre le reste de ce qu'il doit savoir.
• Ant est fiable. Il n'y a pas eu beaucoup de versions de Ant au cours des dernières années parce qu'il fonctionne déjà.
• Les constructions Ant sont reproductibles car elles sont généralement créées sans aucune dépendance externe, comme des dépôts 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 voulez. Si 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 familiarité avec les 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 les conventions que vous voulez. Ainsi, la convention que j'utilise est de mettre mes fichiers sources dans un répertoire nommé 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épertoire utilisée par Maven. Je pense qu'elle a du sens. Aussi leur cycle de vie de construction. J'utilise donc les mêmes conventions dans mes constructions Ant. Pas seulement parce que c'est logique, mais aussi parce que cela sera familier à tous ceux qui ont déjà utilisé Maven.

Answer 3

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 récent, je recommanderais d'utiliser Maven : la "convention plutôt que la configuration" vous fera gagner beaucoup de temps dans l'écriture et la configuration des scripts de construction et de déploiement. Lorsque vous utilisez Ant, le script de construction a tendance à devenir de plus en plus long et complexe avec le temps. Pour les projets existants, il peut être difficile d'adapter leur configuration/modèle dans le système Maven.

Answer 4

La fourmi est principalement un outil de construction.

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

Ant+Ivy est une assez bonne combinaison si vous voulez éviter Maven.

Answer 5

Maven agit à la fois comme un outil de gestion des dépendances - il peut être utilisé pour récupérer des jars à partir d'un référentiel central ou à partir d'un référentiel que vous avez mis en place - et comme un outil de build déclaratif. La différence entre un outil de build "déclaratif" et un outil plus traditionnel comme ant ou make est que vous configurez ce qui doit être fait, pas comment cela doit être 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 repose sur des conventions concernant la manière dont les répertoires de projet sont organisés pour atteindre sa "déclarativité". Par exemple, il a une convention pour indiquer où placer votre code principal, où mettre votre web.xml, vos tests unitaires, et ainsi de suite, mais il donne également la possibilité de les modifier si nécessaire.

Vous devez également garder à l'esprit qu'il existe un plugin pour exécuter des commandes ant depuis 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 archetype Wicket, qui fournit une commande maven que vous exécutez pour obtenir un projet complet, prêt à l'emploi, de type hello world.

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