Maven 2, multi-modules et Subversion : Philosophie ?

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

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.

Je ne suis pas sûr d'avoir compris ce que tu voulais dire :oops:

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.

hum, je sais pas si tu me montres ton arbo svn ou maven :D

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)

Ah oki, je vois mieux ce que tu veux dire :)

:merci:

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.

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

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

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.