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 !
