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.