Migration Maven d'un projet JAVA 7, Strut, Hibernate sous Eclipse

Bonjour,

J'ai un projet web construit de manière "standard" dans Eclipse, les technologies utilisées sont JAVA 7, Struts 2.3, Hibernate 3.6.3 et tout un panel de librairies Apache.

Jusqu'alors toutes les librairies ont étaient ajoutées via la fonction d'Eclipse "Build Path / Configure Build Path...".

Je dois désormais migrer ce projet sous Maven, cela afin de bénéficier de l'ajout des jars et de leur dépendance via le seul fichier de configuration pom.xml . Ce pom devra par ailleurs faire appel à un repository manager distant.

Voici les étapes que j'ai listé pour l'instant :

1 - Choisir le "Repository Manager" et l'installer, pour l'instant je suis parti sur du Nexus, pensez-vous que c'est un bon choix ?
2 - Ajouter les jar de mon projet sur ce repository (en limitant les versions des librairies à celles du projet pour éviter tout conflit).
3 - Créer un nouveau projet sur la base d'un squelette Maven, puis copié mes fichiers contenu dans "Java Resources/src/" directement dans le "src/main/java/" créer lors de la génération du squelette.
4 - Configurer mon fichier pom.xml pour qu'il pointe vers le repository distant (balises <distributionManagement>)
5 - Enfin finaliser la migration par un "clean install" en croisant les doigts pour que les jar soient bien importés..

Voilà je voulais avoir vos commentaires sur mon plan et vous remercie par avance pour vos remarques (étapes manquantes, liens vers tuto, point d'attention particuliers...).

Merci beaucoup !

Quand tu dis les jar de ton projet, tu parles des dépendances internes ou externes?

Pour les dépendances internes, tu devras "maveniser" ces autres projets également (ou les uploader à la main, mais ça va mal finir à coup sûr).
Pour les externes, tu peux mettre ton nexus en proxy devant maven central pour qu'il récupère le nécessaire (en ayant une politique établie de white/black list)

En vrac:

- connecter le scm (svn ou git ou autres) au niveau du pom
- configurer les plugins de compilation (version de Java, version des livrables, etc.) et éventuellelment maven-enforcer
- configurer la génération des jar de sources et javadoc (dans un profile "release" par exemple) parce que c'est plus mieux bien
- configurer les plugins de compilation/validation de jsp pour.... détecter les erreurs dans les jsp
- on peut faire pareil pour p.ex. les templates jasperreport...
- configurer les plugins de tests unitaires, tests d'intégration avec gestion du taux de couverture (cobertura ou jacoco ou autres)
- ajouter/configurer les plugins d'analyse statique de code (cpd, pmd, findbugs, etc) ou même sonar si tu l'as sous la main
- configurer maven-site-plugin pour générer des zolis sites aggrégeant tous les rapports des autres plugins
- configurer maven-release-plugin pour... pouvoir faire des release! (et celui-là fait mal, en général, il est très pénible à utiliser...)
- etc,etc,etc....

Maven c'est bien mais si c'est juste pour gérer les dépendances tu perds 90% de l'intérêt

Citation:

---

Envoyé par yildiz-online

Quand tu dis les jar de ton projet, tu parles des dépendances internes ou externes?

Pour les dépendances internes, tu devras "maveniser" ces autres projets également (ou les uploader à la main, mais ça va mal finir à coup sûr).
Pour les externes, tu peux mettre ton nexus en proxy devant maven central pour qu'il récupère le nécessaire (en ayant une politique établie de white/black list)

---

Il y a des deux. Par "maveniser", tu entends packager les autres projets sous forme de module Maven ?

Citation:

---

Envoyé par Pill_S

En vrac:

- connecter le scm (svn ou git ou autres) au niveau du pom
- configurer les plugins de compilation (version de Java, version des livrables, etc.) et éventuellelment maven-enforcer
- configurer la génération des jar de sources et javadoc (dans un profile "release" par exemple) parce que c'est plus mieux bien
- configurer les plugins de compilation/validation de jsp pour.... détecter les erreurs dans les jsp
- on peut faire pareil pour p.ex. les templates jasperreport...
- configurer les plugins de tests unitaires, tests d'intégration avec gestion du taux de couverture (cobertura ou jacoco ou autres)
- ajouter/configurer les plugins d'analyse statique de code (cpd, pmd, findbugs, etc) ou même sonar si tu l'as sous la main
- configurer maven-site-plugin pour générer des zolis sites aggrégeant tous les rapports des autres plugins
- configurer maven-release-plugin pour... pouvoir faire des release! (et celui-là fait mal, en général, il est très pénible à utiliser...)
- etc,etc,etc....

Maven c'est bien mais si c'est juste pour gérer les dépendances tu perds 90% de l'intérêt

---

Merci pour ces compléments d'information, non en effet ce n'est pas juste pour les dépendances, que l'intégration de Maven est retenue.

Est-il pertinent d'utiliser maven-release-plugin lorsque l'on a déjà Git ? Si oui, pourquoi ?

PS :"parce que c'est plus mieux bien" LOL

Citation:

---

Envoyé par xelm06

Il y a des deux. Par "maveniser", tu entends packager les autres projets sous forme de module Maven ?

---

oui

Citation:

---

Envoyé par xelm06

Est-il pertinent d'utiliser maven-release-plugin lorsque l'on a déjà Git ? Si oui, pourquoi ?

---

Ca depend, de ton flux git par exemple, tu peux avoir à utiliser des altérenatives comme jgitflow.
Maven-release peut aussi être problématique en continuous delivery où la gestion des releases est assez différente du flux standard maven

Citation:

---

Envoyé par xelm06

PS :"parce que c'est plus mieux bien" LOL

---

Argument imparable par excellence :) PS: générer les sources et la javadoc uniquement en mode release permet de gagner quelques minutes sur tous les builds qui ne sont justement pas des "release" (soit 99% des builds...)

Citation:

---

Envoyé par xelm06

Est-il pertinent d'utiliser maven-release-plugin lorsque l'on a déjà Git ? Si oui, pourquoi ?

---

Perso je dirais oui (maven-release coordonne un certain nombre d'outils et fait des vérifications utiles avant de produire une release), mais j'ai surtout fait de l'intégration de Maven dans des environnements svn et du coup je ne suis pas sûr que Git n'arrive pas avec sa liste d'outils moins casse-pieds - en tout cas, conjointement à svn, y'à pas photos, c'est une galère à mettre en place jusqu'à ce que tout fonctionne correctement. Mais après ça fait son taf sans trop s'en soucier.

Le maven release plugin est pas vraiment adapté à git. Il va créer une copie du projet avec les version mise à jour, faire un build de test pour être sur que tout passe, puis va flagger tout dans le repos, faire le build final et uploader vers artifactory. Avec des proécdures assez complexes d'annulation en cas d'erreur.

Avec git, on s'en balance les c*** de la sécurité du build. Si le build passe pas après branch et tagging, on se contente juste de ne pas faire le push et c'est comme si rien ne s'était passé. La complexité des annulations et des pré-tests de release plugin ne sont plus utiles. Seul reste le changement automatique de version :mouarf:
Et pour ça, t'as soir jgitflow (n'est plus développé) si tu suis du gitflow assez simple, soit à la main avec le plugin maven version.

Citation:

---

Envoyé par xelm06

Voici les étapes que j'ai listé pour l'instant :

1 - Choisir le "Repository Manager" et l'installer, pour l'instant je suis parti sur du Nexus, pensez-vous que c'est un bon choix ?
2 - Ajouter les jar de mon projet sur ce repository (en limitant les versions des librairies à celles du projet pour éviter tout conflit).
3 - Créer un nouveau projet sur la base d'un squelette Maven, puis copié mes fichiers contenu dans "Java Resources/src/" directement dans le "src/main/java/" créer lors de la génération du squelette.
4 - Configurer mon fichier pom.xml pour qu'il pointe vers le repository distant (balises <distributionManagement>)
5 - Enfin finaliser la migration par un "clean install" en croisant les doigts pour que les jar soient bien importés..

Voilà je voulais avoir vos commentaires sur mon plan et vous remercie par avance pour vos remarques (étapes manquantes, liens vers tuto, point d'attention particuliers...).

Merci beaucoup !

---

Tu prends les choses à l'envers si tu veux mon avis.

Ta première étape, c'est de construire un pom.xml qui va builder ton projet sans avoir à déplacer les dossiers. Dans la construction de ce pom, tu va devoir faire ta liste de dépendances. Pour les dépendances publiques, utilise un repo public maven existant. Pour les autres installe d'abord en local le temps de tout mettre en place. Cette étape consistera donc principalement à configurer tout les plugins dont tu pourrais avoir besoin pour faire ton build, tes tests, ton packaging.
Ensuite, si tu as des dépendances qui ne sont pas dans un maven public, tu peux commencer à les mettre dans un repo privé, voir à maveniser les autres projets de la même manière.
Enfin, quand ton build fonctionne, tu peux commencer à configurer la partie distribution management, les repository de code, établir des procédure de release pour le projet; ...


Un étape à la fois, tu part de rien et si tu veux tout faire d'un coup, tu va y passer des semaines sans résultat tangible :)

Citation:

---

Envoyé par tchize_

Tu prends les choses à l'envers si tu veux mon avis.

Ta première étape, c'est de construire un pom.xml qui va builder ton projet sans avoir à déplacer les dossiers. Dans la construction de ce pom, tu va devoir faire ta liste de dépendances. Pour les dépendances publiques, utilise un repo public maven existant. Pour les autres installe d'abord en local le temps de tout mettre en place. Cette étape consistera donc principalement à configurer tout les plugins dont tu pourrais avoir besoin pour faire ton build, tes tests, ton packaging.
Ensuite, si tu as des dépendances qui ne sont pas dans un maven public, tu peux commencer à les mettre dans un repo privé, voir à maveniser les autres projets de la même manière.
Enfin, quand ton build fonctionne, tu peux commencer à configurer la partie distribution management, les repository de code, établir des procédure de release pour le projet; ...


Un étape à la fois, tu part de rien et si tu veux tout faire d'un coup, tu va y passer des semaines sans résultat tangible :)

---

Merci pour le conseil, je vais reprendre à la construction du pom.xml

Je dois également intégrer différents profiles (dev, test, prod, etc.). Quelle est la bonne pratique ? D'abord les profiles ou les dépendances ? Ou bien cela est-il complètement indépendant ?

C'est plutôt indépendant, même si les profiles peuvent permettre d'affiner les dépendances en fonction des besoins (genre un profil "websphere8" qui références des dépendances différentes d'un profil "tomcat" par exemple).Par contre ne part pas trop compliqué. C'est une mauvaise idée d'ajouter plein de profils dès le début en se disant "ça servira un jour", avec des règles d'activation obscures ou compliquées. Fais plutôt un pom simple sans profils et ajoute-les quand vraiment tu en as besoins. Ce qu'on trouve souvent, c'est un profile "release" activé uniquement lorsque l'on fait une release et qui inclut plus de plugin (jar de source, javadoc, analyse statique, vérifications, génération du site, etc.). ça permet de ne pas ralentir les builds normaux (ceux qui sont lancés par les développeurs sur leurs postes).

Citation:

---

Ta première étape, c'est de construire un pom.xml qui va builder ton projet sans avoir à déplacer les dossiers.

---

En effet, les fichiers de mon projet ne se trouve pas dans les répertoires par défaut ( src/main/java , src/main/resources, src/main/webapp, etc.).

Par exemple, les sources sont dans deux dossiers : src/ et src-commun/

Ainsi j'ai rajouté les lignes suivantes dans mon pom.xml avant les dépendances

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

... <build> <sourceDirectory>.</sourceDirectory> <plugins> <plugin> <group-id>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <configuration> <includes> <include>src/**/*.java</include> <include>src-common/**/*.java</include> </includes> <source>1.7</sources> <target>1.7</target> </configuration> </plugin> </plugins> </build> ...

---

, du coup je suis tout content... Mon "mvn clean install" renvoi "BUILD SUCCESSFULL" et génère des .class !

Cela dit je me questionne... Dans ce cas, où j'ai deux dossiers de code source Java, un module par dossier n'est-il pas plus propre ?

Si je n'oublie rien (?), il me reste à spécifier les ressources tels que les nombreux fichiers .xml nécessaire à Struts ou encore les icônes utilisés par l'application (tag <ressources>).

Citation:

---

Envoyé par xelm06

Je dois également intégrer différents profiles (dev, test, prod, etc.). Quelle est la bonne pratique ? D'abord les profiles ou les dépendances ?

---

La bonne pratique, c'est "pas de profil" :)
Les profils, ça rend le build dépendant aux profils actif et ça va un peu à l'encontre des principes de maven qui disent que ça doit builder de la même manière partout. Ce qu'on fait en général:

quand on a besoin de path spéficique à l'env de build, c'est définis dans le .m2/settings.xml du developpeur. Par exemple, j'ai un projet avec dans mon settings l'activation du mode debug pour arquillian, histoire qu'eclipse puisse s'y brancher ainsi que les credential artifactory du developpeur.

Les profil, c'est à utiliser quand tu ne peux vraiment pas faire autrement. En gros, si tu dois en utiliser un, demande toi pourquoi ton projet est si tordu que ce serait le cas.

Citation:

---

Envoyé par tchize_

Les profil, c'est à utiliser quand tu ne peux vraiment pas faire autrement. En gros, si tu dois en utiliser un, demande toi pourquoi ton projet est si tordu que ce serait le cas.

---

Autant je suis d'accord que les profils doivent rester l'exception, autant ils sont indispensables dans certains cas, pour ma part je les utilise pour:

-Déployer une image docker sur dockerhub en sus de l'artifact sur maven central, certains CI ne supportant pas le build d'image docker dans un environnement conteneur, cela doit être désactivé dans ces cas.
-Déployer des artifacts multiple avec compilation native sur les différents OS, en cas de compilation sur un OS ne supportant pas la cross compilation (windows par exemple...), obligé de séparer (puis de toute façon, c'est également nécessaire pour gain de temps de build pendant la phase de développement).
-Supporter plusieurs version de java ou d'un framework, par exemple une librairie produisant un artifact compatible spring3 et un autre compatible spring4, ça évite d'avoir des versions majeurs devant suivre le cycle de vie des dépendances plutôt que celui de la librairie elle même.

Citation:

---

Envoyé par yildiz-online

Autant je suis d'accord que les profils doivent rester l'exception, autant ils sont indispensables dans certains cas,

---

Oui, mais ce que tu décris, ce sont des cas complexe, ce n'est pas la majorité des projets. C'est à utiliser quand on a épuisé les autres ressources (paramètres de ligne de commande, paramètres des plugins, profil privé du dev). D'ou le "faut se poser la question d'en quoi le projet / le process est si exceptionel qu'il a besoin de ça"

Clic-droit sur le projet > Configure > Project > Convert to Maven Project.