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.

[mcrogiez]

Lors de mon stage de fin d'étude, il y a 2 ans, j'étais chargé de mettre en place une solution d'intégration continue basée sur Maven 2 et Continuum dans le cadre de la procédure de certification CMMi de ma boîte.

A l'époque, Maven 2 était encore en beta version, mais l'idée et la conception me semblaient bonnes. A l'usage, je lui ai trouvé quand même certaines lacunes.

Avantages :
- Le cycle de vie offre une ossature claire sur laquelle il est facile de s'appuyer pour bâtir ses builds.
- La gestion des dépendances est un réelle bonne idée, mais il faut être bien attentif aux numéros de version et noms des librairies.
- La possibilité de gérer sa repository locale avec les repositories distantes.
- Le grand nombre de plugins disponibles (même s'il n'y a pas que du bon)

Inconvénients :
- L'impact sur les projets : Dans ma boîte, chaque EAR était constitué de 3 jars, d'un jar EJB et d'un war, ce qui nous faisait 5 pom.xml par projet (un peu lourd, on a du bidouiller)
- Maven fait beaucoup de choses (peut-être trop?) mais j'ai souvent été obligé de venir greffer un bon vieux Ant sur certaines étapes du lifecycle Maven pour pouvoir faire ce que je voulais, comme je le voulais.
- Le manque de documentation fait cruellement défaut
- Le Pom est très verbeux à mon goût, notamment la partie dépendances qui est suuuuuuuuuper looooooongue et suuuuuuuuper chiiiiiiiii..... !
- Les plugins pour Eclipse n'apportent rien (mais j'ai pu lire que pour NetBeans et IntelliJ, c'était beaucoup mieux)

Au final, Maven 2 est une idée intéressante et pas trop mal conçue. Mais le manque de doc rend le paramétrage difficile et fastidieux. Pour ma part, sur des gros projets existants, je lui préfère la solution Ant + Ivy. Mais sur de nouveaux projets, pourquoi pas ?

[Jibee]

Romaintaz, voici les pb que nous rencontrions et qui sont corrigés :
- Eclipse affiche chaque module indépendamment, en plus d'une vue globale. Très utile, notamment dans le cas d'un développement Eclipse RCP. Cela prouve aussi que la notion de projet multimodule est enfin prise en compte par le plugin (autre exemple : le menu comporte maintenant une nouvelle option Add Module)
- la gestion des dépendances au niveau workspace fonctionne bien mieux... plus besoin de mvn install, notamment pour faire fonctionner WTP
- update des dépendances SNAPSHOTS possible à la demande

Dans l'ensemble, de gros gros progrés ont été réalisés. Pour ta question sur les projets multimodules, je te conseille de faire l'essai. Je pense réellement que tu seras surpris.

[evenisse]

Il y a aussi Q4E qui fonctionne très bien.