Différences entre Ant et Maven
Quelqu'un pourrait-il me dire les différences entre Ant et Maven? Je n'ai jamais utilisé non plus. Je comprends qu’ils sont utilisés pour automatiser la construction de Java projets, mais je ne sais pas par où commencer.
Dans Maven: Le Guide définitif , 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 comparaison simple
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 fichier de construction 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 ce simple exemple Ant, vous pouvez voir comment vous devez dire à Ant exactement quoi faire. Il existe un objectif de compilation qui inclut la tâche javac qui compile la source dans le répertoire src/main/Java dans le répertoire target/classes. Vous devez indiquer à Ant exactement où se trouve votre source, où vous voulez que le pseudo-code résultant soit stocké et comment le regrouper dans un fichier JAR. Bien que certains développements récents contribuent à rendre Ant moins moins procédural, l'expérience 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, il vous suffit de créer un simple pom.xml, de placer votre code source dans $ {basedir}/src/main/Java, puis de l'exécuter. mvn installer à partir de la ligne de commande. L'exemple Maven pom.xml qui obtient 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 en vue d'une réutilisation dans d'autres projets. Sans modification, vous pouvez exécuter mvn site puis rechercher un fichier index.html dans target/site contenant 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 ou personnalisation. Si nous voulions commencer à personnaliser le comportement, notre pom.xml allait grossir et, dans le plus grand des projets, vous pouvez voir des collections de POM Maven très complexes contenant un grand nombre de personnalisations de plug-ins et de déclarations de dépendance. Cependant, même lorsque les fichiers POM de votre projet deviennent plus substantiels, 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 en src/main/Java". Les fichiers de construction Ant contiennent des instructions explicites: "This is project", "La source est dans src/main/Java", "Exécuter javac contre ce répertoire", "Placez les résultats dans target/classses", " Créez un fichier JAR à partir de .... ", etc. Lorsque Ant devait être explicite à propos du processus, Maven possédait un élément" intégré "qui savait simplement 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 convention formelle comme une structure de répertoire de projet commune, vous devez dire à Ant exactement où trouver le source et où placer le résultat. Les 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. Vous deviez 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 attacher manuellement une séquence de tâches à chaque objectif.
Où Maven ...
- a des conventions, il savait déjà où se trouvait votre code source parce que vous avez suivi la convention. Il a mis le bytecode dans target/classes et a généré un fichier JAR dans target.
- est déclaratif. Tout ce que vous deviez 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é lorsque vous avez exécuté
mvn install. Cette commande a demandé à Maven d'exécuter une série d'étapes de séquence jusqu'à atteindre le cycle de vie. En tant qu'effet secondaire de ce parcours dans le cycle de vie, Maven a exécuté un certain nombre d'objectifs de plug-in par défaut, tels que la compilation et la création d'un fichier JAR.
Qu'en est-il de Ivy?
Bon, alors 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 plus récentes de Ant. C'est vrai. Si vous avez un groupe de personnes intelligentes utilisant Ant + antlibs + Ivy, vous vous retrouverez avec une version bien conçue qui fonctionne. Même si je suis vraiment convaincu que Maven a du sens, j'utiliserais volontiers Ant + Ivy avec une équipe de projet dotée d'un ingénieur de construction très pointu. Cela étant dit, je pense que vous allez manquer un certain nombre de plug-ins de valeur, tels que le plug-in Jetty, et que vous finirez par faire tout un travail que vous n'auriez pas dû faire avec le temps.
Plus important que Maven vs Ant
- Est-ce que vous utilisez un gestionnaire de référentiel pour garder une trace des artefacts logiciels? Je suggérerais téléchargement Nexus . Vous pouvez utiliser Nexus pour créer des proxy sur des référentiels distants et pour fournir à votre équipe un endroit où déployer des artefacts internes.
- Vous avez une modularisation appropriée des composants logiciels. Un grand composant monolithique évolue rarement dans le temps. Au fur et à mesure que votre projet évolue, vous souhaiterez avoir le concept de modules et de sous-modules. Maven se prête très bien à cette approche.
- Vous adoptez des conventions pour votre construction. Même si vous utilisez Ant, vous devez vous efforcer d’adopter une forme de convention compatible avec d’autres projets. Lorsqu'un projet utilise Maven, cela signifie que toute personne familiarisée avec Maven peut se familiariser avec la construction et commencer à l'utiliser sans avoir à manipuler la configuration pour trouver le moyen de la compiler.
Maven est un framework, Ant est une boîte à outils
Maven est une voiture de route préfabriquée, alors que Ant est un ensemble de pièces automobiles. Avec Ant, vous devez construire votre propre voiture, mais au moins, si vous devez effectuer une conduite hors route, vous pouvez construire le bon type de voiture.
En d'autres termes, 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 n'arrêtais pas de bousculer les limites du cadre et que cela ne me laissait pas sortir.
verbosité XML
tobrien est un gars qui connaît beaucoup de Maven et je pense qu'il a fourni une très bonne comparaison honnête des deux produits. Il a comparé un simple pom.xml Maven à un simple fichier de construction Ant et a expliqué comment les projets Maven peuvent devenir plus complexes. Je pense que cela vaut la peine de regarder 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 écrivez moins de XML. J'ai trouvé le contraire pour être vrai. Le fichier pom.xml est 3 fois plus long que le fichier build.xml, sans s'écarter des conventions. En fait, mon exemple Maven est montré sans les 54 lignes supplémentaires nécessaires à la configuration des plugins. Ce pom.xml est pour un projet simple. Le code XML commence réellement à prendre de l'ampleur lorsque vous ajoutez des exigences supplémentaires, ce qui n'est pas inhabituel pour de nombreux projets.
Mais vous devez dire à Ant ce qu'il faut 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. Elles sont définies dans un fichier de construction commun importé par tous les modules du projet multi-modules. Ce qui m'amène à dire que tout cela doit être écrit explicitement dans Ant alors qu'il 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 et qui n'a été que légèrement amélioré depuis. Après mes deux années d’expérience avec Maven, j’ai sorti l’ancien fichier de compilation de fourmi de la garde-robe, je l’ai dépoussiéré et remis au travail. Pour moi, le coût d'avoir à dire explicitement à Ant ce qu'il faut faire a totalisé 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 son effet sur 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 faut que ce soit complexe. Malheureusement, cette complexité a tendance à nier le but recherché.
Comparé à Ant, le concepteur d'un projet Maven consacrera plus de temps:
- Lecture de documentation: Il existe beaucoup plus de documentation sur Maven, car vous en avez encore beaucoup à apprendre.
- Eduquer 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 constructions 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 construction peut ne pas fonctionner correctement.
- Écrire des plugins Maven: Les plugins sont généralement écrits avec une tâche spécifique à l’esprit, par exemple: créer un ensemble de démarrage Web, ce qui rend plus difficile leur réutilisation pour d'autres tâches ou leur combinaison pour atteindre un objectif. Vous devrez donc peut-être écrire l’un des vôtres pour pallier les lacunes du jeu de plug-ins existant.
En revanche:
- La documentation sur les fourmis est concise, complète et au même endroit.
- La fourmi est simple. Un nouveau développeur qui tente d'apprendre Ant n'a besoin que de comprendre quelques concepts simples (cibles, tâches, dépendances, propriétés) pour pouvoir déterminer le reste de ce dont il a besoin de savoir.
- La fourmi est fiable. Ant n'a pas eu beaucoup de sorties au cours des dernières années car cela fonctionne déjà.
- Les constructions Ant sont reproductibles car elles sont généralement créées sans aucune dépendance externe, telles 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 ces outils pour effectuer presque toutes les tâches de votre choix. 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 au diapason. La familiarité avec les produits existants aide à cet égard et les partisans de Maven prétendent à juste titre qu’il s’agit d’un avantage de Maven. Bien entendu, la flexibilité de Ant signifie que vous pouvez créer les conventions de votre choix. Donc, la convention que j'utilise est de placer 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 versions Ant. Pas simplement parce que cela a du sens, mais parce que cela sera familier à quiconque a déjà utilisé Maven.
Ant 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 très bonne combinaison si vous voulez éviter Maven.
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 considérable par écrit et mise en place de scripts de construction et de déploiement. Lorsque vous utilisez ant, le script de construction tend à prendre de la longueur et de la complexité. Pour les projets existants, il peut être difficile d’adapter leur configuration/disposition au système 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ù placer les sorties, etc.
- Ant est procédural. Vous devez dire à Ant exactement quoi faire; dites-lui de compiler, copier, puis compresser, etc.
- Ant n'a pas de cycle de vie.
- Maven utilise des conventions. Il sait où se trouve automatiquement votre code source, à condition de respecter 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 renseignements sur les tâches courantes du projet. Pour exécuter des tests, exécutez simplement mvn test , à condition que les fichiers se trouvent à l'emplacement par défaut. Dans Ant, vous devez d’abord avoir un fichier JAR JUnit, puis créer un chemin de classe qui inclut le fichier JAR JUnit, puis indiquer à Ant où il doit rechercher le code source du test, écrire un objectif compilant la source de test, puis exécuter les tests unitaires. avec JUnit.
Mise à jour:
Cela venait de Maven: Le Guide définitif . Désolé, j'ai totalement oublié de le citer.
Maven agit à la fois comme un outil de gestion des dépendances - il peut être utilisé pour récupérer des fichiers JAR depuis un référentiel central ou depuis 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, et non comment. Par exemple, vous pouvez indiquer dans un script maven qu'un projet doit être présenté sous la forme d'un fichier WAR, et maven sait comment le gérer.
Maven s’appuie sur des conventions relatives à la manière dont les répertoires de projet sont disposés afin d’atteindre sa "déclarativité". Par exemple, il a une convention qui indique où placer votre code principal, où placer votre fichier web.xml, vos tests unitaires, etc., mais 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 à partir de maven:
http://maven.Apache.org/plugins/maven-ant-plugin/
De plus, les archétypes de Maven permettent de démarrer rapidement avec un projet. Par exemple, il existe un archétype Wicket, qui fournit une commande maven que vous exécutez pour obtenir un projet de type hello world complet et prêt à être exécuté.
Je peux prendre une personne qui n'a jamais vu Ant - son build.xml est assez bien écrite - et elle peut comprendre ce qui se passe. Je peux prendre cette même personne et leur montrer un POM Maven et ils n'auront aucune idée de ce qui se passe.
Dans une organisation technique complexe, les gens écrivent à propos des fichiers Ant devenant volumineux et ingérables. J'ai écrit ces types et scripts Ant propres. Il s'agit vraiment de comprendre dès le départ ce que vous devez faire et de concevoir un ensemble de modèles pouvant répondre aux changements et évoluer sur une période de plus de 3 ans.
Sauf si vous avez un projet simple, apprendre les conventions Maven et la manière dont Maven consiste à faire avancer les choses représente beaucoup de travail.
En fin de compte, vous ne pouvez pas prendre en compte le démarrage du projet avec Ant ou Maven: il s’agit vraiment du coût total de possession. L’un des principaux facteurs à prendre en compte est la capacité de l’entreprise à maintenir et à étendre son système de génération sur plusieurs années.
Les aspects les plus importants d'un système de construction sont la gestion de la dépendance et la flexibilité dans l'expression de la recette de construction. Ce doit être un peu intuitif quand bien fait.
Je dirais que cela dépend de la taille de votre projet ... Personnellement, j'utiliserais Maven pour des projets simples nécessitant une compilation, un conditionnement et un déploiement simples. Dès que vous avez besoin de faire des choses plus complexes (nombreuses dépendances, création de fichiers de mappage ...), je passe à Ant ...
Maven abrite également un grand 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 :)) afin de rendre cette partie de la construction d'un projet un peu plus gérable.