1. #1
    Candidat au Club
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    janvier 2016
    Messages
    6
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : janvier 2016
    Messages : 6
    Points : 3
    Points
    3

    Par défaut 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 !

  2. #2
    Membre chevronné Avatar de yildiz-online
    Homme Profil pro
    Architecte technique
    Inscrit en
    octobre 2011
    Messages
    606
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Architecte technique

    Informations forums :
    Inscription : octobre 2011
    Messages : 606
    Points : 2 048
    Points
    2 048

    Par défaut

    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)
    Yildiz-Engine an open-source modular game engine: Website
    Yildiz-Online a 3D MMORTS in alpha: Facebook page / Youtube page

  3. #3
    Membre expert
    Avatar de Pill_S
    Homme Profil pro
    Développeur Java
    Inscrit en
    janvier 2004
    Messages
    2 117
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Finance

    Informations forums :
    Inscription : janvier 2004
    Messages : 2 117
    Points : 3 261
    Points
    3 261

    Par défaut

    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
    Si vous posez une question, c'est que vous voulez une réponse, non? Donc merci de surveiller vos sujets, et de les faire vivre jusqu'à leur résolution !!

    "Si l'aventure vous paraît dangereuse, essayez la routine: elle est mortelle...", Confucius, 531 av. JC

  4. #4
    Candidat au Club
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    janvier 2016
    Messages
    6
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : janvier 2016
    Messages : 6
    Points : 3
    Points
    3

    Par défaut

    Citation Envoyé par yildiz-online Voir le message
    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 ?

  5. #5
    Candidat au Club
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    janvier 2016
    Messages
    6
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : janvier 2016
    Messages : 6
    Points : 3
    Points
    3

    Par défaut

    Citation Envoyé par Pill_S Voir le message
    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

  6. #6
    Membre chevronné Avatar de yildiz-online
    Homme Profil pro
    Architecte technique
    Inscrit en
    octobre 2011
    Messages
    606
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Architecte technique

    Informations forums :
    Inscription : octobre 2011
    Messages : 606
    Points : 2 048
    Points
    2 048

    Par défaut

    Citation Envoyé par xelm06 Voir le message
    Il y a des deux. Par "maveniser", tu entends packager les autres projets sous forme de module Maven ?
    oui

    Citation Envoyé par xelm06 Voir le message
    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
    Yildiz-Engine an open-source modular game engine: Website
    Yildiz-Online a 3D MMORTS in alpha: Facebook page / Youtube page

  7. #7
    Membre expert
    Avatar de Pill_S
    Homme Profil pro
    Développeur Java
    Inscrit en
    janvier 2004
    Messages
    2 117
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Finance

    Informations forums :
    Inscription : janvier 2004
    Messages : 2 117
    Points : 3 261
    Points
    3 261

    Par défaut

    Citation Envoyé par xelm06 Voir le message
    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 Voir le message
    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.
    Si vous posez une question, c'est que vous voulez une réponse, non? Donc merci de surveiller vos sujets, et de les faire vivre jusqu'à leur résolution !!

    "Si l'aventure vous paraît dangereuse, essayez la routine: elle est mortelle...", Confucius, 531 av. JC

  8. #8
    Expert éminent sénior
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    avril 2007
    Messages
    25 017
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2007
    Messages : 25 017
    Points : 47 823
    Points
    47 823

    Par défaut

    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
    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.
    David Delbecq Java Software engineer chez Trimble. TRANSPORT & LOGISTICS.     LinkedIn | Google+

  9. #9
    Expert éminent sénior
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    avril 2007
    Messages
    25 017
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2007
    Messages : 25 017
    Points : 47 823
    Points
    47 823

    Par défaut

    Citation Envoyé par xelm06 Voir le message

    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
    David Delbecq Java Software engineer chez Trimble. TRANSPORT & LOGISTICS.     LinkedIn | Google+

Discussions similaires

  1. Réponses: 2
    Dernier message: 17/10/2014, 10h13
  2. Embarquer Maven dans un projet Java
    Par michel.di dans le forum Développement Web en Java
    Réponses: 0
    Dernier message: 26/01/2012, 11h32
  3. utilisation de Ant ou maven dans un projet Java?
    Par prugne dans le forum Maven
    Réponses: 10
    Dernier message: 20/01/2009, 12h36
  4. struts hibernate sous eclipse
    Par abdel1025 dans le forum Struts
    Réponses: 4
    Dernier message: 19/11/2008, 01h31
  5. projet java/tomcat struts
    Par newmar dans le forum Struts
    Réponses: 6
    Dernier message: 25/02/2008, 11h09

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo