Discussion :

[romaintaz]

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...

[divxdede]

Le seul vrai point noir de Maven est sa mauvaise intégration dans les IDE tel que Netbeans ou Eclipse.

Mais aujourd'hui une autre question peut être soulevée a savoir: "Quelle est la pérénité de cet outil ?"

Car avec Java 7 on aura droit à la même chose avec les JAM.

D'aprés moi, si Maven ne s'intégre pas parfaitement dans les IDE d'ici la sortie de java 7 alors ils sont relativement condamné, car il est fort a parier que les éditeurs comme Netbeans intégreront nativement la gestion des JAM

[eclesia]

tu pourrais peut etre nous définir "JAM" parce que j'en trouve plusieurs définition sur google.

Sinon... je n'aime pas maven, même si je l'utilise pour un projet.

pourquoi je ne l'aime pas ?
-c'est lourd
-ca plante
-ce n'est pas convivial
-c'est mal intégré dans les IDE (je ne pense pas que la faute revienne aux IDE)


On m'a fournit un lien vers quelque chose de différent :
http://raven.rubyforge.org/
Je ne sais pas ce que ca vaut, je n'ai pas encore essayé.

En tout cas, j'espere qu'un jour il y aura un remplacant... pour le moment faut faire avec ce qu'on a

[divxdede]

AdiGuba à écrit un article clair sur son blog concernant les JAM

[millie]

[*]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>.

Ca peut devenir un point négatif. Car quand l'API n'est pas disponible sur le dépôt, c'est pas forcement simple de trouver comme l'ajouter.

Ce qui fait également que pour un novice sachant uniquement les commandes de bases de maven (à savoir mvn archetype:create, mvn package, mvn test, mvn install-test, mvn compile, mvn install, ...), s'il y a un moindre problème (comme la non présence dans le dépot de l'API), ça devient tout de suite galère à résoudre.

[romaintaz]

Ca peut devenir un point négatif. Car quand l'API n'est pas disponible sur le dépôt, c'est pas forcement simple de trouver comme l'ajouter.

Je ne vois pas trop pourquoi...
Moi je voudrais que les 2 écritures soient autorisées :

Code XML :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
<dependencies>
    <!-- Ecriture actuelle: -->
    <dependency>
         <groupId>log4j</groupId>
         <artifactId>log4j</artifactId>
        <version>1.12</version>
    </dependency>
    <!-- Ecriture alternative: -->
    <dependency>log4j:log4j:1.12</dependency>
</dependencies>

Je dis ça surtout pour alléger les pom.xml où tu as plusieurs dizaine de dépendances...

Ce qui fait également que pour un novice sachant uniquement les commandes de bases de maven (à savoir mvn archetype:create, mvn package, mvn test, mvn install-test, mvn compile, mvn install, ...), s'il y a un moindre problème (comme la non présence dans le dépot de l'API), ça devient tout de suite galère à résoudre.

Il est clair que les problèmes sont parfois difficiles à résoudre, même parfois pour quelqu'un qui maitrise Maven !

[millie]

Non, je parle pas juste du bout de phrase "J'aime aussi sa gestion des dépendances, très simple à mettre en place".

C'est effectivement très sympa quand ça marche, mais quand l'API n'est pas sur le dépot, ça marche pas tout seul

[ehsavoie]

Mes deux centimes ....

Je suis d'accord avec les points évoqués jusqu'ici. La documentation est trop parcelaire et plexus est complexe et très mal documenté. J'ai aussi l'impression que 'plexus is the way to go' alors que les outils plus légers comme Proximity et Hudson sont de meilleure facture.
Je pense aussi que l'équipe est trop réduite, notamment pour les plugins 'officiels' ce qui induit des temps de réponse trop long sur les plugins périphériques.
Pour l'intégration avec les IDE, si je suis d'accord pour dire qu'avec Eclipse c'est très pénible, je trouve que pour Netbeans c'est tout à fait satisfaisant.
Enfin je pense qu'il aurait fallu découper le pom en 2 parties : la description du projet (dépendances, développeurs, urls, ...) , et le build à proprement parler avec les plugins.
Ainsi, la partie build serait découplée et l'évolution plus simple.
Emmanuel

[xavier hanin]

Je constate que ce genre de discussion se répand une nouvelle fois, c'est au moins signe d'une chose à mon avis : il n'existe toujours pas d'outil de build pour java qui satisfasse vraiment tout le monde. Est-ce seulement possible ? Difficile à mon avis.

Du côté de Maven 2, je partage l'avis de certains d'entre vous : un bon concept, qui permet de standardiser le processus de build, et permet en théorie de s'appuyer sur l'outil plutôt que de développer ses propres scripts de build.

Dans la réalité, Maven 2 souffre à mon avis d'un manque cruel de documentation précise : par exemple, pour nous dans l'équipe de développement de Ivy, rendre Ivy compatible maven 2 est un vrai casse tête parce qu'on a vraiment du mal à savoir exactement comment la gestion de dépendance de maven 2 est sensée fonctionner. On découvre régulièrement des fonctionnalités non documentées, c'est assez pénible.

Du côté du développement plugin, je n'en ai jamais développé moi même, mais je suis toujours resté effrayé par la rigidité du système. A une époque (révolue ?) pour obtenir la couverture des tests unitaires avec le plugin adequat les tests étaient lancés deux fois : ça montre un peu la rigidité du système. Du côté gestion de dépendance, même si beaucoup apprécient cette fonctionnalité de Maven 2, je rencontre régulièrement des utilisateurs qui passe à Ivy à cause du manque de flexibilité de Maven 2 du côté gestion de dépendances. Le gestion des exclusions est très limitée à mon avis, et le principe des scopes figés montre ses limites dans certains cas. Sans parler de la gestion des repositories plutôt limitée.

Ceci étant dit, tout le monde n'a pas besoin de plus de flexibilité que ce que Maven 2 a à offrir, et dans ce cas je suis tout à fait d'accord pour dire que c'est plutôt un bon outil.

De mon côté je continue à utiliser Ant+Ivy, même si je ne suis pas toujours entousiaste avec certaines fonctionnalités de Ant (Ivy non plus, mais quand ça ne me plait pas je corrige :-)). Maintenant j'ai lancé il y a quelques semaines une discussion sur la mailing list de dev Ant (et sur mon blog) pour essayer de lancer une nouvelle initiative qui essaierait de fournir un système de build prépackagé basé sur Ant+Ivy. L'idée n'est ni neuve ni originale, mais l'interêt soulevé par la discussion pourrait déboucher sur quelque chose dans la communauté Ant (j'ai un premier draft montrant un peu plus le principe du système que je compte soumettre à la communauté Ant), mais là je dérive un peu trop, on est sur un forum Maven là quand même, il faudrait pas pousser :-)

Pour finir une note par rapport à JAM qui a été cité : il s'agit d'une solution aux problèmes de modularités, mais ne permettra certainement pas de s'affranchir d'un bon système de build.

[millie]

A Xavier Hanin : je suis très content qu'un spécialiste en Java et un membre de la JSR (j'ose avoué avoir oublié le numéro, 277 me semble t il) mette son grain de sel dans la discussion.

[xavier hanin]

A Xavier Hanin : je suis très content qu'un spécialiste en Java et un membre de la JSR (j'ose avoué avoir oublié le numéro, 277 me semble t il) mette son grain de sel dans la discussion.

A force d'intervenir sur les mailing list anglophones uniquement j'en finis par oublier que je parle quand même bien mieux français :-) Malheureusement le temps me manque pour intervenir plus souvent par ici :-(
Mais faut pas hesiter à me pinger par e-mail comme Eric l'a fait hier quand le sujet est proche de mes activités.

PS : pour ceux que ça interesse j'ai posté hier mon premier POC de build system basé sur Ant+Ivy: http://people.apache.org/~xavier/easyant-POC-0.1.zip

[gifffftane]

Moi, après quelque hésitations, j'ai choisi d'utiliser Maven que pour créer le jar de mon appli. Ensuite, pour les déploiements eux-mêmes, je suis retourné à Ant.

Je trouve que Maven donne une bonne discipline de développement. Cela ne me gène pas trop qu'il soit mal intégré aux IDE (j'en ai pris mon parti) : je l'utilise pour les tests et installations globales, et c'est une occasion de vérifier que tout fonctionne bien. Je fais régulièrement des clean, test, test-integration (dont je ne sais jamais si c'est pas integration-test) juste pour voir.

De plus, depuis que j'utilise Maven, j'ai enfin un repository auquel je comprends quelque chose !... Avant c'était l'enfer des jars chez moi.

J'ai renoncé à la partie déploiement, à cause de l'incompréhension générale du fonctionnement des plugins fournis pour ça dans Maven ; à quelque chose malheur est bon : du coup mon POM reste léger.

Le problème encore non résolu est la recopie des dépandances dans Ant. (je le fais manuellement). J'ai essayé avec les Maven Task for Ant mais je n'y suis pas arrivé, je ne sais plus pourquoi. Il faudra que j'essaie un jour avec Ivy.

Voilà c'était mon expérience palpitante.

[hugo123]

petite contribution d'un utilisateur,
j'apprécie les plugins associées aux nombreux outils java : couverture de code, javadoc, cargo etc...
Evidemment on peut faire des choses complexes mais ca se paye derrière dans le pom.xml et dans les aléas très récurents des builds : update d'un plugin non voulue et qui plante, conflit de deux jars identiques sur des groups id différents ramenés par transitivités etc...
Le plus gros problème depuis notre passage a maven1 a été les dépendances transitives. Ca part d'une idée intéressante qui est de ramener les dépendances nécessaires d'un projet sans avoir a les connaitre. Effectivement avec un jar comme hibernate c'est pas mal. Mais dans les faits, beaucoup de poms incluents des jars qui devraient être optionnels, des jars avec des group id différents mais qui sont bien les mêmes et au final on n'a fortement l'impression de ne plus maitriser ses librairies (Combien de galères avec xerces par exemple...)

[christopheJ]

J'utilise beaucoup Maven en ce moment pour tester des librairies JSF. j'apprécie de trouver des archetypes tout prêt pour ne pas avoir à me battre avec les dépendances. Quand ils sont configurés avec Jetty en plus c'est un vrai bonheur.

Concernant le support dans les IDE, celui d'intelliJ est excellent. Il suffit de creer un projet avec structure externe, on choisi alors Maven, on pointe le pom.xml racine, confirme les profils que l'on veut et c'est fini.
Si on rajoute une dépendance dans le pom.xml, un clic sur le bouton de synchro et c'est fini..

[aheritier]

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 ??? :-)

[denisC]

Documentation : Je suis complètement d'accord avec vous. La documentation est très souvent critiquée et je pense à juste titre.

Je rajoute juste un commentaire sur ce point: Bien souvent, j'ai trouvé que la documentation sur le site de Maven concernait des plugins dans des versions encore non releasées.
Donc en suivant pas a pas la documentation, rien ne marchait, jusqu'à ce que je me rendre compte que la documentation concernait une version SNAPSHOT du plugin. Et tout ce qui s'en suit pour récuperer cette version et ses dépendances en conservant la stabilité du build.

Pour tout le reste, je suis completement d'accord :
- Pas d'intégration dans Eclipse.
- Grande facilité de gestion du build et des dépendances. La rigidité dont xavier parle ne se rencontre pas si facilement de mon point de vue. Et de toute façon, je me heurte constamment a la rigidité encore plus grande d'Eclipse.
- Les phases de déploiement ont l'air en effet beaucoup plus complexe: Je me suis jusqu'à présent toujours arreté a l'assembly qui produit le zip de mon projet.

[aheritier]

Oui il y a trop régulièrement des erreurs de ce type :-( (Ca me fait penser qu'il faudrait d'ailleurs que je redéploie la version 2.4 du plugin eclipse). On a malheureusement pas encore quelquechose de propre au niveau de la génération du site pour gérer plusieurs versions de la doc en paralelle. Le soucis de base déjà évoqué de nombreuses fois est le fait que l'on ne peut pas séparer la doc technique qui doit etre versionnée, de la doc d'utilisation (qui ne l'est pas obligatoirement), des rapports (qui ne le sont jamais).
Quelles sont ces douleurs sur le déploiement ? Sur le déploiement dans un repository (phase deploy) ou dans un serveur d'app (pour une integration continue par exemple) ?

[gifffftane]

Contre les mises à jour automatiques, il y a tout simplement l'option --offline, non ?

[hugo123]

et plus spécifiquement tu as -npu pour éviter les updates de plugin. D'ailleurs le plugin release utilise cette option par défaut je crois.
Cependant -o pour les dépendances ne peut pas être toujours utilisé dans les phases de dev, idem pour le -npu.

[romaintaz]

C'est tout de même contraignant d'avoir recours à des paramètres en ligne de commande (que l'on peut donc oublier) pour éviter de rentrer dans une situation où possiblement, des bugs pourraient avoir des conséquences non prévisibles sur ton build.
Vivement la 2.0.9 ou 2.1 que les versions des plugins soient obligatoires !