Pfff, forget this mail. Just noticed I was actually too blind to see the error was not the one I wanted to read... Seems like my "brilliant" idea in the end of the previous mail is already what is done...
Thanks anyway and sorry for the noise :-). 2009/4/30 Baptiste MATHUS <[email protected]> > Yes, I already tried it, but the release-plugin resolves the current > revision before release which is still a SNAPSHOT one. So it aborts the > release saying there's a snapshot dependency to be resolved before... > > $ mvn --batch-mode release:clean release:prepare -DdryRun=true > -DautoVersionSubModules=true -DreleaseVersion=2.3.0 - > DdevelopmentVersion=2.4.0-SNAPSHOT > [INFO] Scanning for projects... > [INFO] Reactor build order: > [INFO] Pom parent des projets "socle" > [INFO] Socle Technique (projectA) > [INFO] Socle Fonctionnel (projectB) > [INFO] Searching repository for plugin with prefix: 'release'. > [INFO] > ------------------------------------------------------------------------ > [INFO] Building POM parent des projets MM > [INFO] task-segment: [release:clean, release:prepare] (aggregator-style) > [INFO] > ------------------------------------------------------------------------ > [INFO] [release:clean] > [INFO] Cleaning up after release... > [INFO] [release:prepare] > [INFO] Verifying that there are no local modifications... > [INFO] Executing: cmd.exe /X /C "svn --non-interactive status" > [INFO] Working directory: C:\tests\refacto-multimodules-socle\our-parent > [INFO] Checking dependencies and plugins for snapshots ... > [INFO] > ------------------------------------------------------------------------ > [ERROR] BUILD FAILURE > [INFO] > ------------------------------------------------------------------------ > [INFO] Can't release project due to non released dependencies : > fr.ourcompany:foundation.test:jar:2.3.0-SNAPSHOT:test > in project 'Socle Fonctionnel' > (fr.ourcompany:socle-fonctionnel:bundle:2.3.0-SNAPSHOT) > > I think the release-plugin should try to detect dependencies that matches > those currrently in the reactor, and use the releaseVersion if the > autoVersionSubModules was given. Seems conceptually feasible. What do you > think? > > Cheers. > > 2009/4/30 Jasper de Vries <[email protected]> > > if you make project B dependent on project A with a version of >> ${project.version} it will inherit the version of the parent pom (just >> like >> the build for B does). >> >> On Thu, Apr 30, 2009 at 5:05 PM, Baptiste MATHUS <[email protected]> wrote: >> >> > Hi all, >> > >> > I'm currently stuck in a problem of chicken and egg problem. I already >> read >> > and thought a lot about it. But as I don't think I'll find the best way >> > alone, I'm trying the list. >> > >> > I've read again the following recent thread >> > http://www.nabble.com/Version-Number-Inheritance-td23304326.html but if >> I >> > read it correctly it doesn't speak about the problem I'm encountering : >> > managing the dependency versions. Obviously speaking about the >> dependencies >> > included in the release being done. I hope I'm being clear :-/. >> > >> > Let's explain a bit more the problem with a description and some excerpt >> of >> > my poms. I want to release a multimodule project with the same version >> (as >> > Spring does, for example. They have a bunch of jars, but they always are >> > synced with the same 2.5.1 or so when released. It's far simpler to >> manage >> > it when you need many jars of org.springframework). >> > The thing is some of those modules depend on each other. So when >> releasing >> > them I want to update the dependencies version when it is one of the >> > modules >> > being released. >> > >> > And I want to do it with the littlest set of command. For example, with >> > something like >> > mvn --batch-mode release:prepare -DautoVersionSubmodules=true >> > -DreleaseVersion=2.3.0 -DdevelopmentVersion=2.4.0-SNAPSHOT >> > >> > But this won't work in one pass currently because of the dependencies >> > between modules. >> > >> > Simplified, it gives the following. >> > * parent pom >> > ** projectA >> > ** projectB, which depends on projectA >> > >> > PARENT POM : >> > <project> >> > <groupId>fr.ourcompany</groupId> >> > <artifactId>our-parent</artifactId> >> > <version>2.3.0-SNAPSHOT</version> >> > <packaging>pom</packaging> >> > ... >> > <modules> >> > <module>../projectA</module> >> > <module>../projectB</module> >> > </modules> >> > </project> >> > >> > Project A >> > <project> >> > <parent> >> > <groupId>fr.ourcompany</groupId> >> > <artifactId>our-parent</artifactId> >> > <version>2.3.0-SNAPSHOT</version> >> > <relativePath>../our-parent</relativePath> >> > </parent> >> > <groupId>fr.ourcompany</groupId> >> > <artifactId>projectA</artifactId> >> > ... >> > </project> >> > >> > ProjectB >> > <project> >> > <parent> >> > <groupId>fr.ourcompany</groupId> >> > <artifactId>our-parent</artifactId> >> > <version>2.3.0-SNAPSHOT</version> >> > <relativePath>../our-parent</relativePath> >> > </parent> >> > <groupId>fr.ourcompany</groupId> >> > <artifactId>projectA</artifactId> >> > >> > <dependencies> >> > <dependency> >> > <artifactId>projectA</artifactId> >> > <version>2.3.0-SNAPSHOT</version> >> > <dependency> >> > </dependencies> >> > ... >> > </project> >> > >> > When 2.3.0 is released, projectB 2.3.0 must have its dependency to >> projectA >> > set to 2.3.0 too. And set to 2.4.0-SNAPSHOT in the next development >> version >> > (according to the parameter value up in this mail). >> > >> > I feel maven-release-plugin could handle this quite correctly. What is >> the >> > best way to handle this? Obviously, I'll be happy to write a >> documentation >> > about this kind of release if I'm able to do it. >> > Thanks in advance. >> > >> > Cheers. >> > -- >> > Baptiste <Batmat> MATHUS - http://batmat.net >> > Sauvez un arbre, >> > Mangez un castor ! >> > >> > > > > -- > Baptiste <Batmat> MATHUS - http://batmat.net > Sauvez un arbre, > Mangez un castor ! > -- Baptiste <Batmat> MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
