Comment migrer en douceur vers maven?

Bonjour

Je cherche à mettre peu à peu en place un environnement de production intégrant maven pour optimiser le travail en équipe, mais je me perds un peu dans toutes les technologies qui y sont rattachées. Est-ce que quelqu'un pourrait me clarifier ces concepts et m'expliquer quelles sont les étapes habituelles de mise en place de maven?


J'ai lu la FAQ Maven2 et divers tutoriels, et je comprends bien le principe de l'utilisation en local pour un développeur seul. Par contre, dés que l'on parle de travail en équipe, j'entends aussi parler d'outils d'intégration continue comme continuum (chargé de réaliser les builds automatiques si j'ai bien compris), et de gestionnaires de repository comme archiva (là je ne comprends pas trop à quoi ça sert). Par ailleurs il semblerait qu'il y ait un nombre conséquent de plugins, et que maven 3 soit sorti, mais que la plupart des gens soient restés à maven 2. Tout ceci rend la chose peu claire pour le néophyte ;).

Citation:

---

Envoyé par Aldian

j'entends aussi parler d'outils d'intégration continue comme continuum

---

Tu peux regarder une description ici :
http://linsolas.developpez.com/articles/hudson/#LI-B

En gros, c'est un service qui va périodiquement vérifier ton gestionnaire de sources (CVS, SVN, Git...) et, en cas de modifications du code, va recompiler les sources, relancer les tests, etc.
Son rôle est de s'assurer qu'à tout moment, le code commité par les développeurs est conforme aux attentes (compilation + réussite des tests).
L'un des autres intérêts de l'IC c'est d'exécuter cela dans un environnement sain et non sur une machine d'un développeur (fini le "mais si, ça compile chez moi" ;) ).

Citation:

---

Envoyé par Aldian

de gestionnaires de repository comme archiva (là je ne comprends pas trop à quoi ça sert)

---

Maven, pour compiler un projet, va lire les dépendances définies dans ton pom.xml. Ces dépendances, identifiées par leurs groupId, artifactId et version, sont récupérées depuis un repository distant, puis copiées dans ton repository local. Ainsi, la prochaine fois qu'une dépendance est nécessaire, Maven la récupèrera depuis ton repository local, ce qui est plus rapide.
Le repository distant est en général celui "officiel" de Maven, càd http://repo2.maven.org/maven2/
Mais ce repository ne contient pas tout. De plus, accéder à Internet n'est pas toujours le plus rapide, le plus fiable, pour télécharger des centaines de dépendances (Maven est reconnu pour télécharger la Terre Entière :) ).
Donc en général, ce que l'on fait, c'est de mettre en place un repository d'entreprise (Nexus étant le plus connu, mais il y a aussi Archiva et Artifactory) qui sera le référentiel pour les développeurs. En gros, Maven ira y chercher les dépendances qu'il ne trouve pas en local...

A noter que c'est la même chose pour les plugins Maven.

Citation:

---

Envoyé par Aldian

. Par ailleurs il semblerait qu'il y ait un nombre conséquent de plugins, et que maven 3 soit sorti, mais que la plupart des gens soient restés à maven 2. Tout ceci rend la chose peu claire pour le néophyte ;).

---

Maven 3 est sorti récemment, et je te conseille de t'y mettre. Maven 3 offre de bien meilleures performances, tout en ayant une compatibilité assurée à quasi 100% avec Maven 2 (et donc les plugins).

pour infos, je suis passé de maven 2 à maven3 ici sans m'en rendre compte. J'ai mis à jour mon ide et du jour au lendemain il a préféré utiliser maven 3. Je confirme, compatibilité assurée.

Pour la migration en douceur

1) Oublier Hudson et l'intégration continue. C'est la sucette bien agreable au bout du chemin, mais pas nécessairement un but à atteindre et certainement pas une nécessité

2) Prendre un de tes projets qui ne dépend d'aucun autre projet. Faire l'inventaire de ses dépendances (ce qu'il y a dans le lib/ a priori), commencer à construire le pom en fonction

2b) au fur et à mesure, tu remarquera des dépendances qui pour tout un tas de raisons ne sont pas dans le repo maven officiel. Si possible essaie de les trouver via ce site: http://www.mvnrepository.com . Si introuvables (soit parce que ce sont des librairies commerciales, soit des librairies non mavenisées), tu va devoir te créer un repository local. Le plus simple étant de télécharger, a mon avis, nexus sur une machine serveur, de le mettre en route et de commencer avec (cf la doc de nexus)

3) une fois que le projet compile avec maven, tu passe au suivant

4) t'arrête quand tout est intégré :D

5) t'emmene tout le monde pour un repas pizzas, vin + topo sur maven :D

Je vous remercie vivement de vos réponses détaillées :). Les choses sont désormais beaucoup plus claires, mais il y a deux points que je souhaiterai creuser:

D'une part, comment migrer un projet eclipse vers un projet maven? On trouve un peu partout dans les FAQ la procédure pour créer un projet maven et l'adapter pour Eclipse, mais les documentations sont moins prolixes sur la manipulation inverse. Après il y a surement la possibilité de faire à la main en recréant un archétype et en copiant collant les sources, mais peut être qu'il est possible de procéder de façon plus souple?

D'autre part, comment faut-il configurer le serveur (Linux) ? Y-a-t-il un tutoriel qui s'y rapporte? Bon je suppose qu'il faut y installer Nexus et maven (subversion est déjà là), et que l'ensemble doit plus ou moins être clés en main? Par contre je n'ai pas vu de paquets relatifs à maven3 dans les dépôts, mais comme c'est un logiciel java, ça ne devrait pas poser de problèmes (c'est compatible openjdk?)

si votre projet existe déjà, ne passez pas par l'archetype. Créez un fichier pom.xml de toutes pièces, à partir des pom.xml d'exemple. Déifnissez les source/test/destinations aux même valeurs que vous utilisez dans eclipse. Le plus gros du travail consistera à supprimer les .jar pour les remplacer par des entrées <dependency> de maven. Une fois ça fait, dans eclipse, supprimer le projet et le réimporter depuis le svn comme "projet maven". Les plugins maven pour eclipse font, accessoirement, un très bon boulot aujourd'hui ;)

Pour nexus, il est clé en main, et ne nécessite pas maven3 sur le serveur. Par contre, coté sécurité, avis personnel, c'est la galère à comprendre leur modèle de sécurité. Mais si le serveur n'est pas accessible de l'extérieur, vous n'avez peut etre pas besoin de sécurité :)

Merci beaucoup pour ces infos qui éclaircissent beaucoup de choses:). Je vais creuser tout ça :)

Bon alors j'ai un peu creusé, et je me pose quelques questions sur l'intégration avec Eclipse/Tomcat. Ces deux pages qui datent de 2008 listent bien les possibilités:
http://matthieu-lux.developpez.com/t.../?page=eclipse
http://matthieu-lux.developpez.com/t...n/?page=tomcat

Il se trouve justement qu'à l'heure actuelle, je travaille avec le plugin Eclipse/Tomcat de manière classique: Quand je modifie un fichier source, celui-ci est automatiquement recompilé, et le plugin tomcat pour Eclipse redéploie ensuite le projet. J'aimerai autant que possible que ce comportement ne soit pas modifié par l'utilisation de maven.

A priori, je crois comprendre (corrigez moi si je me trompe) que si je ne configure pas maven pour tomcat, et que je laisse le plugin d'eclipse continuer son job, ça devrait être bon. De la même manière, si j'ai bien compris, je peux laisser à eclipse le soin des compilations usuelles, et n'utiliser maven que lors d'une modification du pom, du moins avec le plugin Maven Eclipse Plugin.

Cependant le tutoriel parle aussi des plugins M2Eclipse et q4e, et donc la question que je me pose est simple: à l'heure actuelle, lequel est le plus recommandé?

les plugins maven pour eclipse s'intègrent à la chaine de compilation de eclipse. Et donc donc configurent le projet pour compiler en utilisant maven. tout le reste de ce qui dépend de la compilation continue à fonctionner sans problème.

Merci de cette réponse. J'ai commencé à essayer d'écrire mon pom.xml. Pour ça j'ai créé un projet vide en utilisant l'archétype "maven-archetype-webapp". J'ai récupéré le pom, et j'ai essayé d'adapter la structure à un projet eclipse de la manière suivante:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>fr.ma-societe.thematique</groupId> <artifactId>projectname</artifactId> <packaging>war</packaging> <version>1.0-SNAPSHOT</version> <name>projectname Maven Webapp</name> <url>http://maven.apache.org</url> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependency> </dependencies> <build> <finalName>projectname</finalName> <sourceDirectory>${basedir}/src</sourceDirectory> <testSourceDirectory>${basedir}/test</testSourceDirectory> <outputDirectory>${basedir}/WebContent/WEB-INF/classes</outputDirectory> <testOutputDirectory>${basedir}/build</testOutputDirectory> </build> </project>

---

J'ai utilisé le plugin m2 d'éclipse, et pour l'instant, j'ai laissé les librairies dans le dossier lib. Ce qui m'ennuie, c'est qu'a priori rien n'indique qu'eclipse utilise maven. Le plugin m2 affiche des lignes de log, mais ne modifie rien. Je pense qu'il ne doit pas avoir compris qu'il fallait utiliser le contenu du dossier WebContent, mais je ne sais pas comment lui indiquer, et la FAQ Maven n'est pas très aidante sur ce coup là.

Je vois bien à la rapidité de tes réponses que tout ça est complètement évident pour toi, mais pour moi c'est comme un mur. Connaitrais-tu un tuto simple et direct qui expliquerait la manip à faire? Je ne dois pas être le premier à me poser la question, comment ont fait les autres?

les $basedir sont inutile, les chemins des ces 4 entrées sont supposées être relatives à basedir

Pour savoir sur le projet est pris 'a la maven', deux choses caractéristique:

Dans les librairies du projet, tu va trouver "system libirairies" pour tout ce qui concerne le JDK et "maven librairies" qui, si tu le déploie indique toutes les librairies dans maven.

De plus, bouton droit sur le projet, tu dois avoir un menu "maven", avec "add dependncy" etc.

Il ne suffit pas qu'un pom.xml soit présent pour que le plugin maven s'en charge. Il faut que le projet eclipse soit créé par le plugin maven. Pour ce faire, en général j'envoie mon premier pom.xml sur le svn, ensuite je fait un close de mon projet eclipse. Puis dans SVN -> bouton droit -> check out as maven projet.

Et c'est partis :)

Bref, la conversion consiste à créer un pom maven (ce que tu as fait) puis ensuite à créer un projet eclipse (checkout as maven projet me semblant le plus simple, y a aussi import maven project dans open project si mémoire est bonne).

Le fonctionnement du plugin eclipse est documenté normalement sur son site meme :)

Merci beaucoup de cet éclaircissement. En ce qui concerne l'import depuis le SCM, pas moyen d'y arriver, la liste déroulante des SCM disponibles est vide et je ne sais pas comment la remplir, mais entre temps j'ai recherché dans une autre direction, j'ai créé un projet j2ee à partir d'un archétype jboss qui contenait déjà toutes les arborescences requises, et j'ai mis mes fichiers à la place des fichiers d'exemple. Ce n'est pas très propre, je me réserve la possibilité de la jouer plus fine quand je comprendrais mieux ce qui se passe.

En attendant, je suis parvenu bon an mal an a avoir un projet maven qui se comporte comme il faut, mais avec encore toutes les librairies dans WebInf/lib. Et puis je me suis attelé à la tache de configurer les librairies dans le pom, ça m'a pris l'après midi car il y en avait 68, dépendances comprises. Au stade où j'en suis, ça compile, ça commence à se déployer, mais ça échoue tout de suite, pour plusieurs raisons: d'abord il y a:

Code:

---

1 2 3 4 5

org.jboss.seam.InstantiationException: Could not instantiate Seam component: Toto Caused by: org.jboss.seam.InstantiationException: Could not instantiate Seam component Bidule Caused by: org.jboss.seam.InstantiationException: Could not instantiate Seam component: hibernateSessionFactory Caused by: org.hibernate.HibernateException: Could not parse configuration: /hibernate.cfg.xml Caused by: org.dom4j.DocumentException: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory Nested exception: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory

---

Cette erreur là, je ne la comprends pas trop. J'ai essayé de placer le fichier hibernate.cfg.xml à divers endroit, ou de l'ajouter au build path, mais sans succès. Après vérification, il s'avère qu'il est bien copié au bon endroit du dossier de déploiement, mais pourtant il n'est pas trouvé, et je me demande s'il n'en est pas de même des autres fichiers (j'ai choisi de configurer Eclipse pour positionner sa sortie de compilation dans le répertoire src/main/webapp/WEB-INF/classes comme dans l'astuce du tuto).

Et puis j'ai aussi la joie de découvrir l'exception que je n'avais encore jamais rencontrée, qui est liée aux soucis de transitivités, je veux parler de:

Code:

---

java.lang.LinkageError: loader constraint violation: when resolving interface method "javax.servlet.jsp.JspApplicationContext.getExpressionFactory()Ljavax/el/ExpressionFactory;" the class loader (instance of org/apache/catalina/loader/WebappClassLoader) of the current class, com/sun/faces/config/ConfigureListener, and the class loader (instance of org/apache/catalina/loader/StandardClassLoader) for resolved class, javax/servlet/jsp/JspApplicationContext, have different Class objects for the type javax/el/ExpressionFactory used in the signature

---

Quoique je ne suis pas certain que ce soit toujours des problèmes de transitivité, c'est peut être simplement des librairies que j'ai mises en "compile" et qu'il aurait fallu mettre en "provided". Toujours est-il que je me suis attelé à la fastidieuse tache de règler les conflits, en me limitant pour l'instant à satisfaire le plus grand nombre. A l'heure actuelle, tout se résume au schéma suivant:
Pièce jointe 75051

A ce sujet, j'ai lu avec intérêt le tutoriel sur la gestion fine des dépendances, mais je ne peux m'empêcher de me poser quelques questions: En effet,

• vu que la plupart des conflits sont dans des dépendances de dépendances de dépendances, et que les exclusions ne sont valides que pour la ramification directement liée, comment faire? Si je commence à spécifier manuellement la version de la dépendance de dépendance de dépendance pour pouvoir en exclure une dépendance, je ne vais pas m'en sortir le jour où je vais vouloir faire évoluer l'application.
• en outre, je me demande comment va réagir la librairie que l'on force du coup à utiliser une librairie différente de ce qu'elle souhaite. Est-ce que ça ne risque pas de causer de problèmes?

Bon Week End à vous!

les deux sont liées à un problème de transitivité. En gros, il existe une série de librairies que jboss aime pas voir dans WEB-INF/lib. Hors maven ramène toutes les librairies avec transitivités dans WEB-INF/lib lors de la génération du war.

A cela, deux solution possibles (une fois les librairies identifiées)
-> Regarder l'arbre maven pour trouver quelle dépendance directe les a amenées et rajouter des exclusion dans l'endrée <dependency> correspondantes. Tu te rendra compte assez vite que c'est peu efficace, les libraires chiantes ayant justement la particularité d'être dans les dépendances de nombreuses librairies directes et indirectes :D Ca reviens presque à les ajouter partout. En plus, ca rend impossiblie l'utilisation directe de ces apis par ton projet.

-> plus propre, rajouter ces librairies bien chiante en temps que dépendances directes de ton application, mais en leur donnant un scope "provided":

Code:

---

1 2 3 4 5 6

<dependency> <groupId>machin</groupId> <artifactId>bidule</artifactId> <version>1.2.3</version> <scope>provided</scope> </dependency>

---

Merci beaucoup de ces conseils! En fait j'utilise tomcat(6). J'en ai refait une installation propre histoire d'être sûr, et en fait beaucoup de problèmes venaient de là. J'ai juste eu à spécifier el-api en provided, suivant tes conseils, et j'ai ajouté en runtime toutes les librairies qui lui ont manqué lors du run.

Maintenant l'application compile, se déploie, et affiche ses vues sans générer d'exceptions. Par contre j'ai quelques problèmes liés au fait que Richfaces ne se comporte pas de la même manière qu'avant (certains noms de classe css ont changé, il y a des bugs javascript, ce genre de choses...), bien que j'ai bien spécifié des versions identiques, je travaille dessus.

EDIT: J'ai trouvé, ça vient de ce qu'en fait le projet utilise une version très légèrement moins récente que la 3.3.3.Final comme je le croyais.

Après ça ayant enfin un pom fonctionnel au niveau des librairies je vais me repencher sur la question du paramètrage de la structure d'un projet eclipse. Normalement je ne dois pas être le premier à faire ça :).

EDIT2: Apparemment il suffit d'ajouter les lignes suivantes dans le pom?

Code:

---

1 2 3

<sourceDirectory>src</sourceDirectory> <testSourceDirectory>test</testSourceDirectory> <outputDirectory>WebContent/WEB-INF/classes</outputDirectory>

---

Je ne comprends pas trop comment maven comprend lors du build que Webcontent correspond au dossier des ressources Web, mais puisque le déploiement se fait bien, ça prouve qu'il y arrive.

Je vais étudier cette histoire de repository local maintenant

Houlà, t'es sur de générer le war avec maven là? Et pas avec ton IDE? C'est pas normal de mettre cette valeur comme outputDirectory.

Normalement tu met un truc genre target/

c'est dans ce dossier que maven mettra la classes compilées (target/classes) les classes de test (target/test-classes), le war généré (target/nomDApplicaiont-version.war) et le war explosé (target/nomDApplication/*)

C'est le plugin war qui, comme un grand, ira collecter ce qui se trouve dans $outputDirectory/classes/ et le mettra dans le WEB-INF/classes du war généré. C'est aussi lui qui ira collecter le contenu web (par défaut webapp/*)

Oui, tu as raison, effectivement c'est l'IDE qui faisait le build (en s'appuyant quand même sur maven pour les librairies à ce qu'il semblerait bien). J'ai fait une analyse plus poussée de la situation, je poste ici ma section build finale pour mémoire et pour les autres gens qui se poseraient la question de configurer maven pour utiliser la structure d'un projet eclipse:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

<build> <finalName>Toto</finalName> <plugins> <!-- Compiler plugin enforces Java 1.6 compatibility and activates annotation processors --> <plugin> <artifactId>maven-compiler-plugin</artifactId> <version>2.3.1</version> <configuration> <source>1.6</source> <target>1.6</target> </configuration> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-war-plugin</artifactId> <version>2.1.1</version> <configuration> <warSourceDirectory>WebContent</warSourceDirectory> <webxml>WebContent/WEB-INF/web.xml</webxml> </configuration> </plugin> </plugins> <sourceDirectory>src</sourceDirectory> <testSourceDirectory>test</testSourceDirectory> <directory>target</directory> <outputDirectory>target/classes</outputDirectory> <testOutputDirectory>target/test-classes</testOutputDirectory> </build>

---

Ce qui est important ici, c'est la surcharge de l'emplacement du dossier webapp. J'ai du creuser très profondément dans la doc maven pour trouver comment faire, parce que par défaut il va chercher dans src/main/webapp, et comme le dossier en question n'existe pas, il pleure. C'est donc l'attribut warSourceDirectory du plugin war qui permet de débloquer la situation.

Concernant nexus, du coup j'ai pas encore trop avancé.

Hop là, il y avait quelques manips bien particulières à faire pour installer nexus sous Ubuntu, j'ai tout détaillé ici.

Concernant maven, je me suis aperçu en le montrant aux collègues qu'il y a deux détails casse gueule dans eclipse:

• Dans Window, Preferences, Maven, Installation, il faut préciser le chemin vers l'installation externe, sans quoi c'est l'installation embarquée, et là on peut éditer tant qu'on veut le fichier settings.xml de Maven_Home/conf, ça n'y changera rien
• Pour un projet J2EE, il faut installer m2eclipse Extras, qui est un plugin différent, et qui ajoute notamment les fonctionnalités WTP intégration (essentielle pour l'export des librairies Maven dans WEB-INF/lib lors du build), et SCM integration, pour l'import d'un projet Maven depuis un SCM

Je reviendrais sans doute, vous poser quelques questions lorsque nous essairons un paramètrage plus poussé de maven, et pourquoi pas l'utilisation de l'intégration continue. En attendant, mon problème est résolu, merci de votre patience :)