Débat Java : Quelle est la philosophie de Maven 2 pour les projets multi-modules ?

Le , par Baptiste Wicht, Expert éminent sénior
Bonjour,

Je travaille actuellement sur un projet multi-modules Maven 2. Je me posais la question de l'intégration dans Subversion comment était la philosophie.

J'ai plusieurs niveaux de modules dans mon workspace local, mais ensuite tous les modules ont leur propre dossier sur Subversion. Le problème étant que les versions de chacun des modules sont indépendantes les unes des autres.

J'aimerais bien avoir une architecture SVN proche de mon architecture locale, mais le problème est que si je garde l'architecture que j'ai en local, je ne pourrai plus tagguer des versions individuelles de modules car je n'aurai plus qu'un dossier trunk et un dossier tags global.

Est-ce que quelqu'un a déja été confrontée à ce problème ?

Y-a-t-il une bonne manière de résoudre ce problème ?

Merci d'avance


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de lunatix lunatix - Rédacteur https://www.developpez.com
le 27/09/2009 à 11:04
bon, c'est avis perso : mais pour moi, si tu dois tagger differement des modules, c'est que c'est des dependances.

un module est l'equivalent d'un deuxieme repertoire de sources dans un projet non maven. il doit suivre le meme cycle de vie que que son pere, et le meme cycle de releases.

si ce n'est pas le cas, c'est que c'est une dependance : il est temps de l'extraire.
Avatar de Baptiste Wicht Baptiste Wicht - Expert éminent sénior https://www.developpez.com
le 27/09/2009 à 11:13
Je ne suis pas sûr d'avoir compris ce que tu voulais dire

En fait, voilà mon arborescence :

JTheque : Projet global
  • JTheque Utilities : Projet contenant des utilitaires
    • JTheque Utils : Des utilitaires généreaux
    • JTheque Launcher : Un simple lanceur
    • JTheque Primary Utils : Des utilitaires spécifiques (dépend de Core et Utils)
    • JTheque Core : Un coeur
  • JTheque Metrics : Une application (dépend de core et utils)
    • ... : des modules pour l'application
  • JTheque Collections : Une autre application (dépend de core, utils et primary utils)
    • ... : des modules pour l'application


Quand tu parles d'extraire, tu penses à créer n repository ? Dans mon cas, ce n'est pas possible malheureusement.
Avatar de lunatix lunatix - Rédacteur https://www.developpez.com
le 27/09/2009 à 12:07
hum, je sais pas si tu me montres ton arbo svn ou maven

moi comment je fais :

projet1(parent pom1)
----module1
----module2

projet2(parent pom2) <-- dependance sur projet1 par exemple)
----module1
----module2

dans svn :

repository
----projet1
--------trunk
------------projets1 et les sous modules de projet 1
--------tags
--------branches

pareil pour le projet 2

si je dois brancher ou tagger un sous module et pas un autre, c'est que ce sous module n'est pas a sa place, et devrait etre projet3 par exemple. je le sort du projet 1, et je crée un projet 3 (potentiellement dans le meme repository)
Avatar de Baptiste Wicht Baptiste Wicht - Expert éminent sénior https://www.developpez.com
le 27/09/2009 à 12:22
Ah oki, je vois mieux ce que tu veux dire



Dans ce cas-là alors je n'aurais que des projets et aucun modules car tous mes modules sont versionnés de manière indépendante...

Mais ce n'est pas vraiment ce que je souhaite, car ce sont vraiment des sous-projets.

Par contre, est-ce que dans le repository, on peut envisager des sous-trunks et branches ?

Du genre ça :

repository
----projet1
--------trunk
------------...
------------module1
---------------trunk
---------------tags

Mais dans ce cas, le fait de tagguer projet1 copie aussi les ancien tags de module1.
Avatar de rseM2 rseM2 - Membre confirmé https://www.developpez.com
le 01/10/2009 à 18:33
Bonjour,

Une des choses qui est pas toujours bien comprise est que l'architecture des projets maven 2 est très dépendante du cycle de vie (au sens release) de différents artefacts.

Pour être plus claire, lorsque tu as plusieurs artefacts, comment choisir entre :
  • un projet multi-modules
  • plusieurs projets simples
  • plusieurs projets multi-modules ou simples


Une des réponses est lié au cycle de vie des artefacts.

Tu regroupes dans un projet multi-modules l'ensemble de tes artefacts qui vont toujours suivre la même version (donc tu vas toujours les releaser en même temps avec la même version). Si a un moment tu souhaites faire une release que d'un module de ce projet, cela veut dire qu'il a son propre cycle de vie et donc qu'il faut envisager de le sortir pour créer un projet propre.

Lorsque tes artefacts ont des cycles de vie différents alors tu fais des projets différents.

Rémy
Avatar de lunatix lunatix - Rédacteur https://www.developpez.com
le 02/10/2009 à 17:53
héhé, je vois que je suis en phase avec rseM2.
un module qui a un cycle de vie differents du projet qui le contient, c'est que ce n'est pas un module mais un projet a part entiere
Avatar de Baptiste Wicht Baptiste Wicht - Expert éminent sénior https://www.developpez.com
le 02/10/2009 à 19:48
Effectivement, vu comme ça, je devrais peut-être les extraire de mon projet. J'avais décidé de les mettre comme sous-modules, parce qu'il m'arrive tout de même de les builder tous ensemble pour du débugage en général et surtout pour bénéficier des facilités offertes par la génération de site pour un projet multi-modules.
Offres d'emploi IT
Technicien support Logiciels de gestion (H/F)
AGENCE SUPPLAY - Aquitaine - Mérignac (16200)
Formateur systèmes et réseaux- h/f
KONICA MINOLTA BUSINESS SOLUTIONS France - Picardie - Glisy (80440)
Consultant confirmé SAP BI BW/IP (h/f)
Atos Intégration - Ile de France - Bezons

Voir plus d'offres Voir la carte des offres IT
Responsables bénévoles de la rubrique Java : Mickael Baron - Robin56 -