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 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 contenues dans cette introduction et quelques notes supplémentaires.

Une comparaison simple

Je vous montre seulement ceci pour illustrer l’idée que, au niveau le plus élémentaire, Maven a des conventions intégrées. Voici un simple fichier de compilation Ant:

  simple example build file                            

Dans cet exemple Ant simple, vous pouvez voir comment vous devez dire à Ant exactement quoi faire. Il existe un objective de compilation qui inclut la tâche javac qui comstack 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 stocker le bytecode résultant et comment regrouper tout cela dans un fichier JAR. Bien que certains développements récents consortingbuent à rendre Ant 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 de certaines sources Java, il vous suffit de créer un simple fichier 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 obtient les mêmes résultats.

  4.0.0 org.sonatype.mavenbook my-project 1.0  

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

Certes, il s’agit du projet d’exemple 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 taille pom.xml augmentera et, dans le plus grand des projets, vous pourrez voir des collections de POMs Maven très complexes qui contiennent beaucoup de déclarations de personnalisation et de dépendances de plug-ins. Mais, même lorsque les fichiers POM de votre projet deviennent plus substantiels, ils contiennent un type d’informations entièrement différent du fichier de génération 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 compilation Ant contiennent des instructions explicites: “Ceci est un projet”, “La source est dans src/main/java “, “Exécuter javac avec ce répertoire”, “Placez les résultats dans target/classses “, “Créez un JAR depuis. … “, etc. Lorsque Ant devait être explicite sur le processus, il y avait quelque chose de” intégré “dans 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…

  • ne possède pas de conventions formelles comme une structure de répertoire de projet commune, vous devez indiquer à Ant exactement où trouver la source et où placer la sortie. 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. Il fallait lui dire de comstackr, puis de copier, puis de compresser.
  • n’a pas de cycle de vie, vous devez définir des objectives et des dépendances d’objectives. Vous deviez attacher une séquence de tâches à chaque objective manuellement.

Où Maven …

  • a des conventions, il savait déjà où votre code source était parce que vous avez suivi la convention. Il place le bytecode dans target / classes et produit un fichier JAR dans la cible.
  • est déclaratif. Il suffisait de créer un fichier pom.xml et de placer votre source dans le répertoire par défaut. Maven s’est occupé du rest.
  • a un cycle de vie, que vous avez mvn install lorsque vous avez exécuté mvn install . Cette commande a demandé à Maven d’exécuter une série d’étapes de séquence jusqu’à ce qu’il atteigne le cycle de vie. Comme effet secondaire de ce voyage à travers le cycle de vie, Maven a exécuté un certain nombre d’objectives de plug-in par défaut, comme la compilation et la création d’un JAR.

Qu’en est-il de Ivy?

Bien, alors quelqu’un comme Steve Loughran va lire cette comparaison et appeler la faute. Il va parler de la façon dont la réponse ignore complètement quelque chose appelé Ivy et le fait que Ant puisse 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 obtiendrez une version bien conçue qui fonctionnera. Même si, je suis très convaincu que Maven a du sens, j’utiliserais avec plaisir Ant + Ivy avec une équipe de projet qui a un ingénieur de construction très pointu. Cela étant dit, je pense que vous finirez par 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’aviez pas besoin de faire au fil du temps.

Plus important que Maven vs Ant

  1. Est-ce que vous utilisez un gestionnaire de référentiel pour suivre les artefacts logiciels. Je suggère de télécharger Nexus . Vous pouvez utiliser Nexus pour proxy de référentiels distants et pour permettre à votre équipe de déployer des artefacts internes.
  2. Vous avez la modularisation appropriée des composants logiciels. Un grand composant monolithique évolue rarement au fil du temps. Au fur et à mesure du développement de votre projet, vous voudrez avoir le concept de modules et de sous-modules. Maven se prête très bien à cette approche.
  3. Vous adoptez des conventions pour votre build. Même si vous utilisez Ant, vous devez vous efforcer d’adopter une forme de convention compatible avec les autres projets. Quand un projet utilise Maven, cela signifie que toute personne familière avec Maven peut prendre la construction et commencer à l’utiliser sans avoir à manipuler la configuration, juste pour comprendre comment comstackr la chose.

Maven est un framework, Ant est une toolbox

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 conduire tout-terrain, vous pouvez construire le bon type de voiture.

En d’autres termes, Maven est un framework alors qu’Ant est une boîte à outils. Si vous vous contentez de travailler dans les limites du cadre, Maven se comportera parfaitement bien. Le problème pour moi était que je n’arrêtais pas de me heurter au cadre et que cela ne me laissait pas tomber.

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 fichier pom.xml de Maven à un simple fichier de compilation Ant et il a mentionné comment les projets Maven pouvaient devenir plus complexes. Je pense que cela vaut la peine de jeter un oeil à une comparaison de quelques fichiers que vous êtes plus susceptibles de voir dans un projet simple et réel. Les fichiers ci-dessous représentent un seul module dans une version multi-module.

Tout d’abord, le fichier Maven:

   com.mycompany app-parent 1.0  4.0.0 persist Persistence Layer   com.mycompany common comstack ${project.version}   com.mycompany domain provided ${project.version}   org.hibernate hibernate ${hibernate.version} provided   commons-lang commons-lang ${commons-lang.version} provided   org.springframework spring ${spring.version} provided   org.dbunit dbunit 2.2.3 test   org.testng testng ${testng.version} test jdk15   commons-dbcp commons-dbcp ${commons-dbcp.version} test   com.oracle ojdbc ${oracle-jdbc.version} test   org.easymock easymock ${easymock.version} test    

Et le fichier Ant équivalent:

                        

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 d’être vrai. Le fichier pom.xml est 3 fois plus long que le fichier build.xml, sans s’éloigner des conventions. En fait, mon exemple Maven est montré sans 54 lignes supplémentaires requirejses pour configurer les plugins. Ce pom.xml est pour un projet simple. Le XML commence vraiment à croître de manière significative lorsque vous commencez à append 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 Ant ci-dessus n’est pas complet bien sûr. Nous devons encore définir les cibles utilisées pour nettoyer, comstackr, tester, etc. Celles-ci sont définies dans un fichier de génération commun importé par tous les modules du projet multi-module. Ce qui m’amène à la question de savoir comment 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 build commun que j’utilise maintenant est celui que j’ai écrit il y a 5 ans avec de légères améliorations depuis. Après mes 2 ans d’expérience avec Maven, j’ai sorti l’ancien fichier de compilation 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 faut faire a été inférieur à une semaine sur une période de cinq ans.

Complexité

La prochaine grande différence que je voudrais mentionner est celle de la complexité et de l’effet réel qu’elle a. 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 génération. Pour ce faire, il doit être complexe. Malheureusement, cette complexité a tendance à nier leur objective.

En comparaison avec Ant, le constructeur sur un projet Maven passera plus de temps:

  • Lire la documentation: Il y a beaucoup plus de documentation sur Maven, car il y a tellement plus à apprendre.
  • Éduquer 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 version: Maven est moins fiable que Ant, en particulier les plug-ins non-core. De plus, les builds Maven ne sont pas reproductibles. 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 rien changé.
  • Écrire des 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 pour les combiner pour atteindre un objective. Il est donc possible que vous deviez écrire un des vôtres pour pallier les lacunes du jeu de plug-ins existant.

En revanche:

  • La documentation Ant est concise, complète et tout en un.
  • 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) pour pouvoir déterminer le rest de ce qu’il doit savoir.
  • Ant est fiable. Il n’y a pas eu beaucoup de sorties de Ant au cours des dernières années car cela fonctionne déjà.
  • Les compilations Ant sont répétables car elles sont généralement créées sans aucune dépendance externe, comme les référentiels en ligne, les plug-ins 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 souhaitées. Si vous avez besoin d’écrire votre propre tâche personnalisée, c’est très simple.

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 connaissance des produits existants aide à cet égard et les partisans de Maven affirment à juste titre que cela profite à Maven. Bien sûr, la flexibilité de Ant signifie que vous pouvez créer n’importe quelle convention. Donc, la convention que j’utilise est de mettre mes fichiers sources 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 c’est logique. Aussi leur cycle de vie de construction. Donc, j’utilise les mêmes conventions dans mes builds Ant. Pas seulement 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 construit bien sûr é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 c’est Maven? sur le site officiel.

edit: Pour un nouveau projet / greenfield, je vous recommande d’utiliser Maven: “convention over configuration” vous permettra d’économiser beaucoup de temps dans l’écriture et la configuration de scripts de génération et de déploiement. Lorsque vous utilisez ant, le script de construction a tendance à croître avec le temps en longueur et en complexité. Pour les projets existants, il peut être difficile de modifier leur configuration / présentation dans le système Maven.

Juste pour énumérer quelques différences plus:

  • 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 comstackr, copier, compresser, etc.
  • Ant n’a pas de cycle de vie.
  • Maven utilise des conventions. Il sait où votre code source est automatiquement, tant que vous suivez ces conventions. Vous n’avez pas besoin de dire à Maven où c’est.
  • Maven est déclaratif; Il suffit de créer un fichier pom.xml et de placer votre source dans le répertoire par défaut. Maven s’occupera du rest.
  • 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 possède des informations sur les tâches courantes du projet. Pour exécuter des tests, exécutez simplement le test mvn , tant que les fichiers sont à l’emplacement par défaut. Dans Ant, vous devez d’abord créer un fichier JAR, puis créer un chemin de classe incluant le JAR JUnit, puis indiquer à Ant où rechercher le code source du test, écrire un objective qui comstack la source de test et enfin exécuter les tests unitaires. avec JUnit.

Mettre à jour:

Cela vient de Maven: The Definitive Guide . 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 outil de génération déclaratif. La différence entre un outil de génération “déclaratif” et un outil plus traditionnel comme ant ou make est que vous configurez ce qui doit être fait, et non comment il est fait. Par exemple, vous pouvez dire dans un script Maven qu’un projet doit être empaqueté en tant que fichier WAR et que maven sait comment gérer ce problème.

Maven s’appuie sur des conventions sur la manière dont les répertoires de projets sont présentés pour atteindre sa “capacité de déclaration”. Par exemple, il a une convention pour savoir où placer votre code principal, où placer votre fichier web.xml, vos tests unitaires, etc., mais vous permet également de les modifier si nécessaire.

Vous devez également garder à l’esprit qu’il existe un plug-in pour exécuter les commandes ant depuis maven:

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

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

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

Je peux prendre une personne qui n’a jamais vu Ant – ses build.xml s sont raisonnablement bien rédigés – et ils peuvent comprendre ce qui se passe. Je peux prendre cette même personne et leur montrer un PMA Maven et ils n’auront aucune idée de ce qui se passe.

Dans une organisation d’ingénierie très vaste, les utilisateurs écrivent sur les fichiers Ant qui deviennent de plus en plus volumineux et ingérables. J’ai écrit ces types et nettoyé les scripts Ant. Il est essentiel de comprendre ce que vous devez faire dès maintenant et de concevoir un ensemble de modèles pouvant répondre aux changements et à l’échelle 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 travail considérable.

Au bout du compte, vous ne pouvez pas considérer le démarrage du 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 construction sur quelques années est l’un des principaux facteurs à prendre en compte.

Les aspects les plus importants d’un système de construction sont la gestion des dépendances et la flexibilité dans l’expression de la recette de construction. 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 nécessitant une compilation, un conditionnement et un déploiement simples. Dès que vous aurez besoin de faire des choses plus compliquées (beaucoup de dépendances, créer des fichiers de mapping …), je passerais à Ant …

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