Discussion :

[jaubert]

Bonjour,

J'ai l'erreur suivante lors d'une release sur un projet modulaire :
[INFO] [release:prepare]
[INFO] Resuming release from phase 'scm-commit-release'
[INFO] Checking in modified POMs...
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] An error is occurred in the checkin process: E:\projects\Maven\workspace-maven\P1\pom.xml was not contained in E:\projects\Maven\workspace-maven\P2

Architecture des modules :
Parent/pom.xml
P1/pom.xml
P2/pom.xml
Nb : P1 depend de P2, les 2 projets sont fils de Parent

Quelqu'un sait-il a quoi cela est-il dû ? et la solution pour que la release marche ?

[evenisse]

Quel est ton SCM?
Tes projets sont-ils dans le meme repository? dans le même trunk?
Quels sont tes scm url?

[jaubert]

Quel est ton SCM?
Tes projets sont-ils dans le meme repository? dans le même trunk?
Quels sont tes scm url?

1) Mon SCM : CVS
2) Les projets en question n'appartiennent pas à la même branche.
3) Je n'ai pas mis d'accès web au repository CVS (dans le pom la developerConnection et la Connection sont identiques : "scm:cvs:pserver:user@serveur.entreprise.fr:/path/cvsroot:${project.artifactId}")

[jaubert]

En fait cela correspond plus ou moins au problème énoncé ici :
http://jira.codehaus.org/browse/MREL...VGcmzxvdGky82g

Une solution autre qu'attendre la prochaine version ?

[evenisse]

La solution est de faire une release par projet et non global.
De toute façon, si dans le plugin release, nous implémentons le support de plusieurs ROOT pour les modules, c'est probablement ce que nous ferons.

[jaubert]

En somme, si je veux automatiser mes releases, je dois ecrire un plugin qui va lire les modules déclarés dans le projet parent (le chemin relatif vers ces modules) et qui va lancer les goals que je souhaitent, en l'occurrence le release:prepare et perform, ou ecrire un script batch ou ant dans lequel il faudra faire un copier/coller des modules, tout en oubliant pas du coup de m'occuper des dépendances, en attendant une future version du plugin qui implémente cette fonction quelle que soit l'arborescence des projets (et notamment pour une meilleure compatibilité avec eclipse...) ?

Cela est dommage.

Je me sens comme un windowsien voulant passer à Linux mais qui ayant beau essayé ni parvient pas faute d'etre assisté ...

Merci Emmanuel.

[evenisse]

Pas tout à fait, il te faut un petit script, si tu veux, mais simpliste. Ce qu'il faut que tu fasse, c'est:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
cd projet1
mvn release:prepare
mvn release:perform
mise à jour de la version de projet1 dans pom du projet2
cp projet2
mvn release:prepare
mvn release:perform

Pourquoi n'estce pas encore géré dans le plugin release? Tout simplement parce que nous considérons que des projets étant dans différentes branches ne forment pas un seul projet (sinon, il serait dans la même branche), c'est pourquoi, il est nécessaire de les releaser indépendamment. Cependant, je pense qui nous autoriserons ce cas de figure car tu es la deuxième personne à le demander (pas beaucoup ).
Regarde dans jira, je crois qu'il y a une entrée pour ce pb.

Sinon, avec la nouvelle version de continuum que nous allons sortir très prochainement, il est très simple de faire une release avec un "wizard"

[jaubert]

Merci Emmanuel.

Je vais placé ce post en résolu, même si pour moi le pb persiste car le petit script n'est pas du tout pratique pour une certaine automatisation des builds.
Ce qui était intéressant dans le plugin release couplé au concept de projet multimodules, c'était qu'il pouvait releaser tout un ensemble de projets en une fois, une seule commande.

Mais j'aurai souhaité étendre la notion de projet multimodules au fait qu'un groupe de projets peut nécessiter, en plus des modules qui lui sont propres, de builder des modules qui ne font pas partie de lui à proprement parlé (architecture en couches : la couche entreprise commune à plusieurs groupes de projets peut évoluer en fonction de l'évolution d'un groupe de projets parmi les autres, sur une branche associée à certains groupes, etc.) d'où le fait que j'essaie de faire un release sur des projets n'appartenant pas forcément à la même branche.
Pour moi, le concept de projet multimodules ne devrait pas s'arrêter au simple fait que l'on a un projet et ses modules dans un coin, puis un autre projet avec ses modules dans un autre, etc., mais plutôt un projet avec des modules qui peuvent être partagés avec d'autres, appartenir à d'autres branches que le projet ensembliste de base, etc. --> la prise en compte de tout ce qui est nécessaire au build d'un projet ensembliste, d'où que cela provienne.
Peut-être que l'architecture en place n'est pas forcément appropriée, mais on ne peut se permettre de la redéfinir au vu de l'ampleur des projets, et on se retrouve plus ou moins coincé pour automatiser proprement (NB : je suis plutôt perfectionniste...) les builds des projets.

Merci en tout cas et j'attends avec impatience les évols de Maven et ses plugins, ainsi que de Continuum et Archiva.

PS : j'ai créé un pom multimodule avec 2 projets d'une même branche et j'ai la même erreur.