Je voudrais contrer quelques-unes des plaintes formulées dans ce forum:
Maven est tout ou rien. Ou du moins pour autant que je puisse dire d'après la documentation. Vous ne pouvez pas facilement utiliser maven en remplacement de la fourmi et adopter progressivement des fonctionnalités plus avancées.
Ce n'est pas vrai. La grande victoire de Maven est de l'utiliser pour gérer vos dépendances de manière rationnelle et si vous voulez faire cela dans maven et faire tout le reste dans ant, vous pouvez. Voici comment:
<?xml version="1.0" encoding="UTF-8"?>
<project name="foo" basedir="." xmlns:maven="antlib:org.apache.maven.artifact.ant" >
<maven:dependencies verbose="true" pathId="maven.classpath">
<maven:pom id="maven.pom" file="pom.xml" />
</maven:dependencies>
</project>
Vous avez maintenant un objet classpath nommé «maven.classpath» qui contient toutes les dépendances maven définies dans le fichier pom. Tout ce dont vous avez besoin est de mettre le fichier jar des tâches maven ant dans le répertoire lib de votre fourmi.
Maven rend votre processus de construction dépendant de votre connexion réseau.
Le processus de récupération des dépendances et des plugins par défaut dépend d'une connexion réseau, oui, mais uniquement pour la construction initiale (ou si vous modifiez les dépendances ou les plugins utilisés). Après cela, tous les fichiers JAR sont mis en cache localement. Et si vous voulez forcer la connexion sans réseau, vous pouvez dire à maven d'utiliser le mode hors ligne.
Il vous impose une structure rigide dès le départ.
Ce n'est pas clair si cela fait référence au format de fichier ou au problème de la «convention contre la configuration». Pour ce dernier, il y a beaucoup de valeurs par défaut invisibles comme l'emplacement attendu des fichiers source java et des ressources, ou la compatibilité de la source. Mais ce n'est pas de la rigidité, il s'agit de mettre des valeurs par défaut raisonnables pour vous afin que vous n'ayez pas à les définir explicitement. Tous les paramètres peuvent être remplacés assez facilement (bien que pour un débutant, il puisse être difficile de trouver dans la documentation comment changer certaines choses).
Si vous parlez du format de fichier, eh bien c'est couvert dans la réponse à la partie suivante ...
Il est basé sur XML, il est donc aussi difficile à lire que l'était ANT.
Tout d'abord, je ne vois pas comment vous pouvez vous plaindre du fait qu'un aspect de quelque chose «N'est pas meilleur que la fourmi» pour justifier une mauvaise réputation. Deuxièmement, bien qu'il soit toujours XML, le format du XML est beaucoup plus défini. De plus, comme il est ainsi défini, il est beaucoup plus facile de créer un éditeur de client lourd sensible pour un POM. J'ai vu des pages longues et créer des scripts qui sautent partout. Aucun éditeur de script de construction de fourmis ne rendra cela plus acceptable, juste une autre longue liste de tâches interconnectées présentées d'une manière légèrement différente.
Cela dit, il y a quelques plaintes que j'ai vues ici qui ont ou avaient une certaine validité, la plus grande étant
- La documentation est pauvre / manquante
- Constructions reproductibles
- L'intégration d'Eclipse est mauvaise
- Bugs
A quoi ma réponse est double. Premièrement, Maven est un outil beaucoup plus récent que Ant ou Make, vous devez donc vous attendre à ce que cela prenne du temps pour atteindre le niveau de maturité de ces applications. Deuxièmement, si vous ne l'aimez pas, corrigez-le . C'est un projet open source et l'utiliser, puis se plaindre de quelque chose que tout le monde peut aider à résoudre me semble assez absurde. Vous n'aimez pas la documentation? Contribuez-y pour le rendre plus clair, plus complet ou plus accessible à un débutant.
Le problème des builds reproductibles se décompose en deux problèmes, les gammes de versions et les mises à jour automatiques du plugin maven. Pour les mises à jour du plugin, à moins que vous ne vous assuriez, lorsque vous reconstruisez un projet un an plus tard, que vous utilisez exactement le même JDK et exactement la même version d'Ant, bien c'est juste le même problème avec un nom différent. Pour les gammes de versions, je recommande de travailler sur un plugin qui produira un pom temporaire avec des versions verrouillées pour toutes les dépendances directes et transitives et l'intègrera au cycle de vie de la version maven. De cette façon, vos poms de build de version sont toujours des descriptions exactes de toutes les dépendances.