Maven est-il le meilleur outil pour faire des builds ?
Bonjour,
Je lance un débat, dont le sujet principal est l'intitulé de mon post : Maven est-il le meilleur outil pour faire des builds ?
En fait, j'ai vu hier un post intéressant sur InfoQ à propos de la question.
Bon, c'est en anglais, mais l'idée de cet article est de soulever les problèmes actuel de Maven.
Ce qui est le plus souvent reproché à Maven :- Une documentation peu adaptée : documents manquant ou difficiles à trouver, site peu clair, etc.
- Complexité globale de l'application.
- Problème sur les plugins (en particulier dû au fait que l'on ne force pas la version dans son pom.xml, ce qui peut poser des problème si un plugin est mis-à-jour et qui contient des erreurs)
- Les métadonnées sont trop complexes, en particulier sur les repositories.
- L'intégration de Maven2 dans les IDE.
Une conclusion que beaucoup s'accorde à donner est que Maven est basé sur une très bonne idée mais qu'elle a été piètrement implémentée...
Mon point de vue:
Personnellement, j'ai appris à me servir de Maven2 (je n'ai jamais utilisé Maven1) peu après sa sortie, et je m'y suis formé un peu au grès de mon projet. J'ai eu assez vite une formation (un cours du soir) grâce à ma SSII ce qui m'a permis de bien mieux le maitriser. J'ai depuis donné plusieurs formations Maven2 dans ma SSII mais aussi sur ma mission.
Tout ça pour dire que j'ai donc été aidé pour mon apprentissage.
De fait, je suis assez content de Maven 2, et j'aurais du mal à repartir sur un projet sans Maven 2...
Toutefois, je suis assez d'accord sur certains points :- La documentation est assez sommaire sur certains aspects de l'outil, même si quelques bons livres existent et permettent de mieux comprendre l'outil ("The Definitive Guide" ou "Better builds with Maven").
- Le développement de plugins est assez simple une fois qu'on a un peu compris le principe, mais hélas la documentation et les aides à ce propos sont peu nombreuses et peu claires. Je me souviens comment j'ai galéré comme un malade pour comprendre comment je pouvais obtenir la liste de toutes les dépendances dont les transitives du projet sur lequel le plugin est exécuté !
- Les métadonnées des repositories sont en effet une plaie...
- Très clairement, LE point noir est son intégration avec les IDE. Malgré les plugins (m2eclipse ou q4e), on est encore très loin de la gestion correcte des projets Maven par Eclipse, Netbeans ou IDEA... Par exemple impossible de gérer correctement un projet multi-modules...
Franchement, j'aime beaucoup de choses dans Maven 2:- Avec un pom.xml assez simple, on peut faire plein de choses : compiler un projet, lancer les tests, créer un site de toute pièce...
- J'aime aussi sa gestion des dépendances, très simple à mettre en place, quoique j'aimerais pouvoir écrire une dépendance plus simplement, comme par exemple : <dependency>log4j:log4j:1.0</dependency>.
- J'aime aussi le principe des plugins, bien que j'approuve le fait que leur version devrait être obligatoire dans leur déclaration des pom.xml...
- Le principe de "Convention over Configuration" est une bonne chose : en utilisant les conventions de Maven (répertoire de sources par exemple), on limite les informations peu utiles dans le pom.xml.
- L'intégration aisée de projets Mavenisé dans des outils d'Intégration Continue (en particulier Hudson, où il suffit de lui fournir le pom.xml et c'est tout).
- Une fois le concept acquis, le développement de plugins est assez simple. Du moins si on veut faire des choses pas trop complexes...
- Plusieurs autres choses que j'ai oublié sans doute ;)
Ma conclusion serait de dire que Maven 2 est un très bel outil, bourré de fonctionnalités intéressantes, mais dont la complexité et la difficulté à trouver des informations sont un frein à une plus grande adoption...
En somme beaucoup de lacunes peuvent encore être comblées dans les prochaines versions de Maven...
Voilà voilà. Je lance le débat.
Je sais que sur ce forum, vous utilisez tous Maven (c'est logique), alors qu'en pensez vous ?
Si vous avez déjà utilisé d'autres outils de builds tels Ant, Ivy, Buildr, etc. un avis / comparatif peut être intéressant...
Un point de vue de l'intérieur
Bonjour à tous,
Comme Xavier, j'ai effectivement peu l'habitude (et le temps) de suivre les forums français. Ce qui est d'autant plus dommage puisque nous sommes sommes plusieurs francophones dans l'équipe Maven.
Je vais essayer de répondre à vos questions en tant que participant à ce projet.
Documentation : Je suis complètement d'accord avec vous. La documentation est très souvent critiquée et je pense à juste titre. Le site web n'est pas clair et pas facile d'accès lorsque l'on démarre avec maven en tant qu'utilisateur. C'est pour pallier à cela qu'il y a désormais les deux livres disponibles gratuitement chez devzuz.com et sonatype.com. Ils sont mieux structurés et permettent de rentrer dans le sujet pas à pas.
Compléxité : Sniff je dirai. Il est regretable justement que n'importe qui doivent mettre le nez trop profondement dans le produit. Cela reste trop souvent le cas. Rien que pour configurer le projet en java 5 il faut le faire au niveau de 3 ou 4 plugins selon l'utilisation. C'est nul. C'est un axe d'amélioration que l'on doit poursuivre.
Plugins : La mise à jour automatique est effectivement une grosse bétise qui devrait disparaitre en 2.1 et peut-être même en parti en 2.0.9 (les versions reconnues stables par notre équipe seront préconfigurée dans le superpom). L'idée était séduisante mais effectivement nefaste à l'usage car nous ne sommes pas capable de délivrer des plugins sans bugs (c'est la quete du graal) et donc imposer la mise à jour automatique peut avoir des effets trop nefastes (genre le plugin buggé qui vient s'installer le jour de la release de votre projet...). Le seul work-around et best-pratice a suivre est de référencer toutes les versions dans votre projet ou dans un pom parent partagé par tous vos projets si vous êtes en environement d'entreprise.
Metadonnées : Elles ne sont pas vraiment complexes par contre leur qualité n'a pas toujours été au top pour une grande partie des projets distribués. Cela demande de notre part une grande evangélisation des projets à l'utilisation de maven et surtout à la déclaration des dépendances.
IDEs : La dessus nous n'avons pas été vraiement aidées par les communautés. J'en connais même certaines qui cherchais la petite bête pour nous ennuyer. Cela s'améliore cependant. IntelliJ ou netbeans proposent une intégration très acceptable. Le plugin eclipse de maven fonctionne pas trop mal et permet de rendre son utilisation transparente pdt 70% du dev avec le support de WTP par exemple. Pour une intégration plus forte avec eclipse il faudra attendre Q4E qui devrait devenir le support officiel de maven 2 dans eclipse. Pour l'instant il ne supporte que le futur maven 2.1 (du fait de la reécriture de l'embeddder de maen) mais prochaine il fonctionnera aussi en 2.0.X.
JAM : Même si cela changera pas mal le packaging des applis en Java, il n'y aura qu'un effet restreint sur maven car ce dernier ne se limite pas du tout à cette tâche.
Le développement de plugins : Oui la aussi c'est la galère pour rentrer dedans même en faisant partie de la communauté. Plexus & les X plugins a connaitre pour ecrire son plugin et ses tests c'est la galère. Au niveau doc je vous conseille : irc.codehaus.org#maven. Il y a tout de même quelques docs interessantes dans les bouquins sus-cités mais il existe aujourd'hui dans l'archi 2.0 des bugs ou des limitations sur galères pour l'écriture de plugins (réutilisation de mojos impossible, etc). En 2.1 il y aura aussi un effort de fait de ce coté. En 2.0 vous pouvez aussi faire simple en écrivant vos plugins en groovy. Ca allège un peu le travail. Prenez exemple sur les plugins écris ainsi chez mojo.codehaus.org.
La lourdeur du POM : Même si ça n'est pas encore intégré, un membre de notre équipe a joué à rajouter le support de POMs qui utilisent des attributs XML (au lieu de tous les enfants à feuille unique). Plus d'info ici : http://blogs.exist.com/bporter/2008/...ng-attributes/
Sinon aujourd'hui Maven n'est peut être pas la solution miracle mais c'est aujourd'hui la seule qui puisse adresser la dimension "entreprise" du build en proposant des standards, en permettant de factoriser les efforts (par exemple en distribuant un ou des poms parents à vos projets), en traitant nativement les problématiques de reporting et controle de la qualité.
Donc si vous vouloez nous aidez, n'hésitez surtout pas. Nous sommes à l'écoute même si il faut bien l'avouer le gateau est très gros pour l'équipe que nous sommes. Des volontaires ??? :-)