Discussion :

[Escoba]

Je suis tout à fait d'accord avec l'ensemble des idées énoncées à propos de Maven2. Ca va faire un an que je l'utilise sur différents projets et j'en suis satisfait malgré le manque de doc et autres problèmes déjà évoqués. Je pense également que Maven2 doit obligatoirement devenir mature avant l'arrivée de Java 7 et de JAM.

[romaintaz]

Je pense également que Maven2 doit obligatoirement devenir mature...

Peux-tu nous en dire un peu plus long à ce sujet ? Je veux dire qu'est-ce qui fait (ferait) que Maven2 devienne mature à tes yeux ?

[Escoba]

Peux-tu nous en dire un peu plus long à ce sujet ? Je veux dire qu'est-ce qui fait (ferait) que Maven2 devienne mature à tes yeux ?

La résolution des différents problèmes précédemment évoqués (notamment la documentation) et surtout une meuilleur intégration dans les IDE (a mon avis c'est ça qui repousse beaucoup de développeurs à utiliser Maven)

[aheritier]

Vivement la 2.0.9 ou 2.1 que les versions des plugins soient obligatoires !

En attendant, il est plus que conseillé de définir ces versions dans le pom de votre projet ou dans un pom parent si vous en avez un. Ca vous evitera bien des soucis. N'oubliez pas non plus de spécifier la version minimum de maven 2 qui est necessaire pour builder votre projet.

[nicmarti]

J'ai integré et géré des projets avec Ant et Maven2. Voici un point de vue en tant qu'éditeur de logiciel.

Je travaille sur des logiciels qui ont des cycles de vie assez long, et nous utilisons Maven2 pour construire, packager, tester et retro-documenter notre produit.
Tout d'abord si votre besoin n'est que de construire votre produit, en dehors de votre IDE, je vous conseille de rester à Ant. En effet, traverser la rivière pour aller vers Maven2 ne vaut le coup (et le coût) que si votre choix est aussi de prendre à fond toutes les propositions de maven2.
Est-ce que vous pensez utiliser ces fonctions ?

• gestion des dependances transitives (tout ce qui est externe à votre projet)
• mise en place de la gestion de version de votre logiciel (vous ne restez pas en 1.0-SNAPSHOT
• generation de statistiques et de couverture de code (qualité)
• installation automatique de votre application J2EE vers un serveur d'appli
• tests fonctionnels
• packaging de l'application (préparation du DVD)
• ...

Maven2 encore une fois, vous fera gagner du temps pour mettre ces solutions en place. Il est donc intéressant d'investir lorsque vous développez un logiciel sur le long terme. Est-ce que cela reste intéressant pour un projet de quelques mois ? je dis non.

Autre chose: nous avons eu rapidement besoin d'un proxy/repository Maven2 pour nos différents logiciels. Sinon l'interêt d'utiliser maven2 n'était plus là. Et aujourd'hui j'avoue que ça marche plutôt bien. Attention cependant, il nous a fallu un gros effort afin d'écrire des plugins spécifiques. De même presque 3 semaines ont été nécessaires pour mettre en place correctement la génération d'un site chaque nuit avec les caractéristiques de nos produits, les résultats des tests unitaires, et la couverture du code.

Bref attention aux coûts cachés de Maven2: la documentation n'étant pas forcément accessible, il vous faudra quelqu'un avec de fortes compétences dans l'équipe pour avancer. Sinon comme je le disais avant: rester à Ant pour compiler et faire de l'intégration continue.
C'est simple et ça marche.

Nicolas

Voir aussi ce vieux post:
http://www.touilleur-express.fr/2007...-la-vraie-vie/

[romaintaz]

Merci pour ton avis, nicmarti.

Toutefois 2 choses :

1. La gestion des dépendances transitives ? Je dirais qu'on est un peu toujours obligé d'avoir des dépendances transitives, à moins de n'avoir que très peu de dépendances sur son propre projet. Maintenant, il est clair que d'utiliser Maven2 uniquement pour cet aspect des choses, c'est un peu léger...

2. Maven 2 a un coût certain, comme tu le montres, en particulier lorsque c'est la 1e fois que l'on s'y met...
Maintenant, il faut aussi considérer l'expérience que l'on acquière en utilisant Maven 2. Il est vrai qu'il est peu intéressant de se mettre à Maven 2 en commençant par un tout petit projet.
J'ai personnellement utilisé Maven 2 pour de gros projets, mais si aujourd'hui je devais me lancer sur un petit projet, alors je n'hésiterais pas à utiliser Maven 2...

[grunt2000]

Maven est très séduisant mais il devient vite très irritant.

Maven: pour les nouveaux projets, pas pour ceux existants.
Débutez un projet avec Maven, et je pense que tout ira dans l'ordre.

Migrez un projet ANT ou autre vers Maven, et là, vous allez souffrir. En particulier, parce que certains paramétrages de plugins font des fragments XML aux allures d'épitaphes tant ils sont longs et peu justifiables.
Et de quoi avez-vous l'air quand votre pom.xml est devenu plus compliqué que le build.xml dont il était issu?


Alpha 2 contre bêta 4
Ce que ça download comme choses étranges Maven! Et quel côté rassurant il a! Tel composant viendra en version bêta et l'autre en version alpha. Si l'exécution échoue, un -X pour un debug sera peut-être nécessaire. Et vous de devoir compléter des dépendances de plugins avec telle ou telle API, ou de paramétrer leur exécution de manière improvisée, inattendue et intempestive après une recherche faite sur Internet auprès des victimes du même problème. C'est long, c'est fastidieux, et c'est souvent symbole du côté sympathique mais aussi bricolé des différents plugins.


Proposer Maven dans son entreprise, il faut avoir le moral
ANT tout le monde comprend comment cela fonctionne assez rapidement. Il est toujours explicable. Maven, c'est autre chose. Un an suffit-il pour être capable de résoudre toutes ses avanies? Rien n'est moins sûr.
L'aspect patouille de nombreux plugins associé à leur documentation souvent indigente font que l'idée porter un grand projet sous Maven n'inspire pas facilement confiance. Cela fonctionnera:
- Au bout de combien de mois?
- Pendant combien de mois?

[Tarul]

Alpha 2 contre bêta 4
Ce que ça download comme choses étranges Maven! Et quel côté rassurant il a! Tel composant viendra en version bêta et l'autre en version alpha. Si l'exécution échoue, un -X pour un debug sera peut-être nécessaire. Et vous de devoir compléter des dépendances de plugins avec telle ou telle API, ou de paramétrer leur exécution de manière improvisée, inattendue et intempestive après une recherche faite sur Internet auprès des victimes du même problème. C'est long, c'est fastidieux, et c'est souvent symbole du côté sympathique mais aussi bricolé des différents plugins.

Ce n'est parce qu'il y a une mise à jour du plugin?

A mon avis, en entreprise, on devrait utiliser un repository maven certifié en interne. Ce dernier disposant de plugins (même taggé en beta) testé par une équipe de dev. ou a défaut, toujours préciser la version du plugin choisi, on évite ainsi de voir ainsi des téléchargements étrange ou inconnu.

Je pense aussi que pour utiliser maven, il faut appliquer la même rigueur que pour l'utilisation et la création des autres scripts. en production, on utilise des scripts dûment testés et documentés. Pour utiliser maven, il faut utiliser des plugins dûment testés et contrôlés. Je pense(mais bon je n'ai pas de pratique réelle et professionnel) qu'avec ce genre de pratique, on est indépendant de la connexion internet de la boite et on contrôle tout ce que fait maven.(on évite des updates de plugin qui peuvent apporter des problèmes.

Et de quoi avez-vous l'air quand votre pom.xml est devenu plus compliqué que le build.xml dont il était issu?

Je n'ai pas pu rencontré ce genre de cas, mais il faut montrer les autres services rendus par maven. par exemple dans le scm, il n'y a pas les librairies nécessaire à la compilation et si on passe par maven pour livrer ou pour tagger, il peut vérifier que les tests unitaire passent bien.

Mais je ne suis pas étonné de voir que le coût de migration d'ant vers maven soit élevé. Mais je pense qu'un pom bien établit devrait moins bougé qu'un script ant.

[nicØB]

Bonjour,

Pour ma part je développe en amateur et j'ai apprit à utiliser maven. J'en suis assez content, à part quelques problèmes déjà exposés ici.

Je pense que ce qui m'agace le plus c'est que ça ne s'intègre pas bien à Eclipse (ou alors je m'y prends mal). Par exemple, pour récupérer les sources d'un projet avec plusieurs modules ça devient vite la galère. On a une arborescence hiérarchique et des fichiers POM partout, et par conséquent ce n'est pas vraiment gérable...
Je ne sais pas trop si la faute vient d'eclipse qui (je pense) ne sait pas gérer les "hiérarchie de projets" ou bien de maven. Par contre, un nouveau plugin pour eclipse est prévu vers septembre 2008 environ. Alors cela améliorera peut être les choses.

Question documentation, le meilleur moyen que j'ai trouvé est de voir comment font les autres personnes dans des projets de taille conséquente, et je m'en sors assez bien comme ça.
Bref, c'est vraiment à revoir. Par exemple, dans le "Getting Started in 30 Minutes" le déploiement de l'application n'est même pas abordé et l'est dans un mini guide (Guide to creating assemblies).

[afkkir]

je suis tout à fait d'accord avec toi nicØB.

En ce moment j'essaye d'utiliser maven pour automatiser les builds d'un projet plugin eclipse et son update site. Le développement des plugins Eclipse doit respecter quelques contraintes bien définies et en plus de ça les dépendances du projet ne sont pas à jour dans ibiblio (ou dans les autres dépôts public) voir même absentes.

J'essaye de trouver des pistes pour ces problèmes mais je n'y arrive pas encore faute du nombre médiocre des sujets traitants ce sujet.

Pour les dépendances (plugins Eclipse) j'utilise eclipse:to-maven pour générer les artefacts correspondants. Pénible à faire: mettre à chaque fois eclipse à jour pour générer ensuite les artefact.

Conclusion : Maven Eclipse

[Nithril]

L'idée de lifecycle est excellente ainsi que celle de repository.

La gestion des dependences souffrent des projets n'utilisant pas Maven. On est obligé de créer un POM associé et de l'uploader sur un repository.

La configuration du fichier POM est trop verbeux, trop complexe.

Maven ne permet pas simplement la definition de tache simple.

Et enfin l'integration avec Eclipse n'est pas assez poussé.

[Jibee]

Concernant l'intégration avec Eclipse, je vous conseille d'essayer la dernière version de m2eclipse (0.9.4) avec le dernier Eclipse (+ WTP). Ca fonctionne très bien maintenant !

A part la gestion du pom, on ne fait plus rien qui ressemble à du maven pour développer, déployer en local et tester.

Seul bémol, la gestion des repo distants qui a changé et nécessite de créer sur le repo un index de ce qu'il contient... pas très pratique, surtout s'il faut mettre à jour cet index pour voir les nouveautés depuis les postes de dev (à confirmer, pas encore testé... qqn a des infos là dessus ?)

[romaintaz]

Merci pour le retour. Et la gestion des projets multi-modules avec héritage, il gère ça comment ?

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

[pdeville]

J'utilise maven2 depuis plus d'un an et je dois dire que je lui trouve beaucoup d'avantages. La gestion des projets et moins lourde qu'avec ant : il suffit de definir les d'ependances par rapports aux autres projets ou par rapport aux librairies disponibles. De plus avec le plugins m2 eclipse au son homologue sur netbeans cette partie et franchement a la portee de tous. Ce que japprecie vraiment beaucoup c'est qu'il impose une certaine discipline (standardisation) au niveau de l'architecture des projets.

[fabs0028]

Bonjour,

j'ai eu à utiliser maven dans le cadre d'un projet de dernière année d'étude. Nous avions plus ou moins le choix entre maven et ant mais nous étions fortement poussé vers le choix de maven.

Je me suis occupé de la mise en place de maven dans mon équipe et plusieurs points ressortent. Il s'agit toutefois des principaux points qui ont été cités précédemment :
- Manque de documentation claire : pour un néophyte en la matière, c'est très long de bien découvrir cet outil et d'en tirer le mieux parti.
- Manque d'intégration à éclipse : ça ne facilite vraiment pas l'usage de maven.

Dans mon cas, le 1er projet utilisant maven était un projet j2ee assez complexe (surtout en débutant dans la sphère j2ee par la même occasion) et j'avoue m'être pas mal cassé la tete sur l'organisation multi projets.
Un autre point que je note est le problème de l'intégration avec WTP : à l'heure actuelle il m'est toujours impossible d'allier efficacement maven et eclipse : en effet, je souhaiterai pouvoir déployer mon application directement par eclipse tout en profitant de la gestion de dépendance de maven. Malheureusement, les dépendances gérées par maven ne sont pas prises en compte par eclipse et bien que l'application se déploit correctement, elle n'embarque pas les librairies nécessaires à son bon fonctionnement.

A coté de ces problèmes, je considère tout de même maven comme un très bon outil qui simplifie énormément la vie sur un ensemble important de taches de packaging jusqu'au à l'intégration continue avec hudson.

De mon point de vue, une intégration efficace à eclipse (qui semble d'ailleurs être en pleine discution actuellement) et une documentation plus claire et mieux référencée ferait de cet outil une vrai pière angulaire des développements java.

[PurpleOwl]

Avec WTP 2.0.x et m2eclipse, il est possible d'ajouter le container des dépendances Maven en tant que module J2EE, et donc d'embarquer les librairies qu'il contient lors du déploiement par Eclipse (excepté que j'avais des problèmes avec le packaging WAR pour intégrer en tant que dépendances les projets présents dans le même workspace).

En-dehors de ça, j'ai suivi les conseils de Jibee et j'ai installé la version en cours de développement de m2eclipse (0.9.5), et pour ce que j'en ai vu, je suis plutôt enthousiaste (surtout par rapport à ce que j'avais pu voir avant - mais j'avoue que j'ai peu testé Q4E, ayant besoin d'un outil qui s'intégrait aussi dans Eclipse 3.2, ou le plugin Maven Eclipse). Je suis d'autant plus déçue par la création des EAR et EJB (non reconnus comme tels par Eclipse), mais vu les progrès faits pour les WAR j'attends la suite ^^ , ce qui permettrait de bénéficier pleinement de la gestion (que je considère enfin comme existante) multi-modules (car j'ai actuellement le choix entre créer un sous-module OU créer un EAR/EJB de façon classique avec Eclipse). J'ai aussi quelques problèmes avec la recherche des dépendances qui ne sont pas sur les repos distants...

En ce qui concerne l'utilisation de Maven (parce que je suis un peu hors-sujet, désolée ), j'aime les idées mais je manque encore de recul pour la pratique, et donc pour faire un vrai commentaire...

[Loizo]

Pour ce qui est de l'integration de Maven2 et de Netbeans il faut avouer qu'elle est tres bonne. J'utilise NetBeans 6.1 et le plugin Maven. Tout fonctionne parfaitement contrairement à Eclipse ou nous avons rencontré beaucoup de difficultés !