Gradle vs Maven

Allez, petit compte rendu relatif à ce poste : Toulouse JUG

Mercredi 16 mars, première réunion de Toulouse Jug nouvelle édition, dans les locaux de l’Epitech. Débriefing rapide au début de la conférence, l’équipe a l’air vraiment sympathique et motivée, et la bonne humeur était au rendez-vous 🙂 Rien que ça, ça donne plutôt envie d’y retourner et de soutenir autant que faire se peut l’initiative… Bon, je redonnerai l’adresse du site de Toulouse JUG plus tard, pour une sombre histoire de propriété de nom de domaine et de nouvelle association, le nouveau site a l’air en construction. Cependant, une adresse mail : toulouse-jug@googlegroups.com . Maintenant, parlons de ce qui nous intéresse et du thème de la soirée : Gradle vs Maven

Déjà, quelle est la problématique de ces outils ?
Du développement à la mise en production (comprendre là que l’application est utilisable et utilisée), l’application va être soumise à tout un processus que l’on retrouvera plus ou moins équivalent d’un projet informatique à un autre.
Développement -> Mise en conf (SVN, Git…) -> Compilation -> Déploiement sur une machine d’intégration
Ce processus, répété aussi souvent que nécessaire, peut être complété par différents outils d’audit de code (Sonar…). L’intérêt est de surveiller la qualité du code produit tous les jours, d’automatiser les tests unitaires (JUnit…) ainsi que faciliter mise en intégration, en toutes autres choses… Bref, c’est clairement un workflow (suite d’évènements interdépendants) qui se doit d’être automatisé pour faciliter la tâche de l’équipe de développement.

Pour ce faire, nous pouvons nous appuyer sur une architecture classique telle qu’un serveur Jenkins (application web capable, en gros, de lancer des scripts périodiquement…). Et nous arrivons enfin au point qui nous intéresse: Jenkins va être capable de lancer des outils d’intégration continus tels que Ant, Maven, ou Gradle. Historiquement, Ant est en quelque sorte le précurseur… C’est tout simplement un outil de script en XML, très puissant, mais passablement lourd à écrire et à maintenir. C’est l’outil que j’utilise pour ma part, parce que tout était déjà écrit en Ant, et qu’autour de moi les scripts utilisés sont aussi en Ant… Bref, je l’utilise par obligation 🙂 Je donnerai mon avis sur Gradle et Maven3 avec ce que j’ai retenu de la présentation des deux orateurs, d’un oeil neuf et neutre, et présenter l’intérêt que je peux leur trouver en comparaison à Ant.

Gradle

la présentation a été faite par Grégory Boissinot, qui a eu la gentillesse de me donner un lien vers ses slides. J’ai trouvé que ça reflétait bien la philosophie générale et les différents aspects de Gradle, je vous laisse donc les parcourir…

Alors, quoi en penser ?
Ce que j’en retiens, c’est que c’est conçu pour être totalement flexible, et pratique, à travers Groovy (entre autre). J’en retiens aussi que ça a l’air jeune, avec par exemple mauvaise intégration à Eclipse, et une liste de plugins plus restreinte que ses concurrents… Donc voilà, ils ont apparemment tout fait pour qu’on puisse automatiser un processus dont le contenu est totalement customisable, en évitant un maximum de contrainte au développeur.
Juste un petit détail sur un point qui me laisse quand même perplexe. Gradle permet de « s’insérer dans l’existant » facilement (slides 50…). Je comprends bien que rien que stratégiquement, proposer ce genre de chose est un moyen plus simple d’entrer dans un « marché » déjà existant. Cependant, par exemple sur tous les projets sur lesquels je travaille, tous les scripts d’intégration sont basés sur Ant et j’avoue que je serais réticent à encapsuler tout ça par une autre techno. N’est-ce pas un risque de complexifier la maintenance ? Je pense qu’à un moment un choix doit être fait non ?

Maven3

Présentation effectuée par Arnaud Héritier.

Ce que j’ai beaucoup aimé dans sa présentation, c’est qu’il l’a faite avec un œil critique sur l’outil qu’il venait présenter. Et manifestement, il avait à dire 🙂 . Maven, beaucoup de gens dans l’assemblée connaissaient déjà, il a donc préféré montrer clairement ce qui n’allait pas dans Maven 2, et montrer en quoi Maven 3 tentait de rectifier le tir…
Pour ma part, je n’ai jamais utilisé Maven non plus (Tout l’intérêt pour moi était d’ailleurs là…). Si j’avais du en tirer un bilan immédiat après la présentation, la première chose qui me serait venu à l’esprit c’est « Usine à gaz » 🙂 Pas forcément au mauvais sens du terme d’ailleurs… Maven, c’est manifestement une communauté immense, un support, un développement constant, des axes d’amélioration, et en découle des outils plus pratiques qu’avec Gradle (plugin Eclipse…). En gros, Maven, tout le monde y a un peu touché et est capable de faire quelque chose avec un peu d’investissement. Et dans le monde de l’entreprise ne pas avoir à capitaliser l’expérience n’est pas un mince atout… Après, dans les défauts que j’aurais retenu, c’est le mauvais côté de l’usine à gaz : problèmes de performances, plugins plus ou moins compliqués à développer et surtout : sa rigidité. Si Maven ne vous permet pas de faire quelque chose, alors que vous en avez absolument besoin, et bien…. Changez de techno. Le problème a l’air vraiment récurrent, au moins d’après les témoignages à la conférence, Arnaud Héritier ayant acquiescé.

 

Deux technos pour deux utilisations différentes, comme bien souvent… Je pense qu’il faut essayer les deux, voir, se confronter aux problèmes, et ce sont les projets eux-mêmes, avec leurs contraintes, qui décideront de quel outil d’intégration vous avez besoin…
Pour en savoir plus sur ces outils, les slides proposés par nos intervenants font référence à toute la documentation officielle, très complète dans les deux cas. Il faut se lancer !

En tout cas merci à nos deux intervenants, et à Toulouse Jug pour la soirée, c’était très chouette ! 🙂