Faut-il passer à Maven 3 ?
Maven 3 est sorti depuis quelques mois, et ne propose que peu de nouvelles fonctionnalités au développeur qui l’utilisera. Quelles sont ces nouveautés ? Pour les projets utilisant Maven 2, faut il les passer sur la nouvelle version ? Réponse courte : oui. Aujourd’hui, il y a peu à gagner, mais la rétrocompatibilité est presque totale. Pour plus de détails, lisez la suite…
Une plus grande rapidité dans le build.
Deux améliorations permettront une plus grande rapidité de build : une gestion des entrées/sorties (I/O) plus efficace, et le fait de pouvoir construire//tester en parallèle, tirant mieux parti des processeurs multi-cœurs. Pour illustrer cette évolution, j’ai choisi de construire Struts 2 avec Maven 2, avec Maven 3, puis avec Maven 3 en lui forçant deux threads en parallèle (option -T 2). Struts 2 est un projet de plus de 100 000 lignes de code, réparties sur 38 modules. Le module « core » contient à lui seul près de 800 tests unitaires. Voici les résultats. Ils ont été réalisés sur un Core 2 Duo, avec 8Go de ram et un ssd.
| 1 seul module | | | 38 modules | | | | --- | | | --- | | | --- | --- | --- | --- |
| Maven 2 | Maven 3 | Maven 3 -T 2 | Maven 2 | Maven 3 | Maven 3 -T 2 |
|---|---|---|---|---|---|
| 57 sec | 56,486 sec | 56,440 sec | 8 min 41 sec | 8 min 11 sec | 6 min 23 sec |
Sur un projet ne contenant qu’un unique module, la différence ne se fait presque pas sentir. Sur un SSD, je suppose que les optimisations d’I/O ne sont pas significatives. Par contre, sur le projet de 38 modules, le gain est de 25%.
En multi-modules, Maven 3 optimise votre build, en construisant en parallèle vos différents modules. Cela pose quelques contraintes. Si tous vos modules forment une chaîne de dépendances, impossible d’en construire plusieurs en parallèle. Au contraire, si vos dépendances sont légères, Maven 3 améliorera vos performances.
Par ailleurs, si vous construisez en parallèle, pensez à vos tests, particulièrement ceux d’intégration. Partagent-ils une base de données en commun ? Dans ce cas, partagent-ils la même donnée ? Vous pourriez alors avoir des surprises.
Que va t’il falloir changer sur mon projet ?
Pour réaliser le test, je n’ai pas eu besoin de changer les pom.xml. La rétro compatibilité est forte.
Au niveau des plugins, beaucoup sont immédiatement compatibles. En voici une matrice de compatibilité.
Si à la sortie, certains logiciels connexes ne fonctionnaient pas avec Maven 3, tous le supportent aujourd’hui. Jenkins (ou Hudson) intègrent Maven 3 depuis janvier. Le plugin m2eclipse est également compatible avec Maven 3. C’est d’ailleurs la version qui est intégrée avec m2eclipse, lorsque vous le téléchargez depuis le site d’Eclipse Indigo.
Parmis les plugins incompatibles, vous trouvez Maven Site. Une version beta compatible est actuellement disponible.
Sinon, la liste des soucis de compatibilité est disponible.
Validation du pom plus stricte
Une nouvelle fonctionnalité est particulièrement utile. Désormais, Maven est plus strict sur la validité des fichiers pom.xml. Par exemple : si vous avez une erreur d’héritage, Maven 3 refusera de compiler au début plutôt que de planter au milieu. Si vous avez déclaré la même version d’une dépendance dans votre parent et dans votre sous module, Maven vous enverra un warning.
M2Eclipse intègre ces warnings. Dans Eclipse, il vous indique directement les lignes auxquelles il faut faire attention, dans vos pom.xml. Du coup, on peut corriger immédiatement et simplement ces petites choses qui peuvent vous poser problème un jour.
Et voilà !
Il existe des projets connexes. Avec une extension, vous pouvez écrire vos pom dans d’autres langages que le xml. Il existe une console, qui vous permet de gagner le temps de démarrage de Maven. La version 3.1 intégrera peut être les mixin. Je ne doute pas que d’autres projets de ce type existeront prochainement. Faut il migrer dès aujourd’hui à Maven 3 ? Ca ne coûte pas grand chose, cela peut optimiser votre build, et ça vous prépare à l’avenir.