1. #1
    Candidat au Club
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    janvier 2016
    Messages
    8
    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 : 8
    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 émérite Avatar de yildiz-online
    Homme Profil pro
    Architecte technique
    Inscrit en
    octobre 2011
    Messages
    672
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Architecte technique

    Informations forums :
    Inscription : octobre 2011
    Messages : 672
    Points : 2 250
    Points
    2 250

    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 120
    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 120
    Points : 3 265
    Points
    3 265

    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
    8
    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 : 8
    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
    8
    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 : 8
    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 émérite Avatar de yildiz-online
    Homme Profil pro
    Architecte technique
    Inscrit en
    octobre 2011
    Messages
    672
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Architecte technique

    Informations forums :
    Inscription : octobre 2011
    Messages : 672
    Points : 2 250
    Points
    2 250

    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 120
    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 120
    Points : 3 265
    Points
    3 265

    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 111
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : Belgique

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

    Informations forums :
    Inscription : avril 2007
    Messages : 25 111
    Points : 48 013
    Points
    48 013

    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 111
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : Belgique

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

    Informations forums :
    Inscription : avril 2007
    Messages : 25 111
    Points : 48 013
    Points
    48 013

    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+

  10. #10
    Candidat au Club
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    janvier 2016
    Messages
    8
    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 : 8
    Points : 3
    Points
    3

    Par défaut

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

  11. #11
    Membre expert
    Avatar de Pill_S
    Homme Profil pro
    Développeur Java
    Inscrit en
    janvier 2004
    Messages
    2 120
    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 120
    Points : 3 265
    Points
    3 265

    Par défaut

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

  12. #12
    Candidat au Club
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    janvier 2016
    Messages
    8
    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 : 8
    Points : 3
    Points
    3

    Par défaut

    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
     
    ...
    <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>).

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

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

    Informations forums :
    Inscription : avril 2007
    Messages : 25 111
    Points : 48 013
    Points
    48 013

    Par défaut

    Citation Envoyé par xelm06 Voir le message

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

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

    Informations professionnelles :
    Activité : Architecte technique

    Informations forums :
    Inscription : octobre 2011
    Messages : 672
    Points : 2 250
    Points
    2 250

    Par défaut

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

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

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

    Informations forums :
    Inscription : avril 2007
    Messages : 25 111
    Points : 48 013
    Points
    48 013

    Par défaut

    Citation Envoyé par yildiz-online Voir le message
    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"
    David Delbecq Java Software engineer chez Trimble. TRANSPORT & LOGISTICS.     LinkedIn | Google+

  16. #16
    Membre chevronné
    Avatar de Mickael_Istria
    Homme Profil pro
    Développeur Expert Eclipse RCP
    Inscrit en
    juillet 2008
    Messages
    992
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Expert Eclipse RCP
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2008
    Messages : 992
    Points : 2 057
    Points
    2 057

    Par défaut

    Clic-droit sur le projet > Configure > Project > Convert to Maven Project.
    Tu fais du JEE/Web/Mobile dans Eclipse? Essaye JBoss Tools !
    Read my blog about Eclipse | Follow me on twitter

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