You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Baptiste MATHUS <ml...@batmat.net> on 2009/04/30 17:05:23 UTC
Multimodule release with same version for everything and dependency
version update
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 !
Re: Multimodule release with same version for everything and
dependency version update
Posted by Baptiste MATHUS <ml...@batmat.net>.
True, Zac.
For those who might wonder, this bug is the one that forces you to add the
-DpreparationGoals="clean install" (see my previous messages) when releasing
so that it finds the right version on the hd since it's currently unable to
retrieve them through the reactor.
Cheers.
2009/5/15 Zac Thompson <za...@gmail.com>
> Baptiste, it seems like you and I are trying to do very similar
> things. I have just got back to my efforts in this area, and I am
> blocked by an issue that sounds very similar to yours. I just found
> it in the following:
>
> http://jira.codehaus.org/browse/MNG-3023
>
> It seems that the multi-module update-everything release-plugin
> approach is really only viable for Maven 2.1.0 or above (unless you
> want to always have all the snapshots installed before you release)
>
> On Mon, May 4, 2009 at 1:26 AM, Baptiste MATHUS <ml...@batmat.net> wrote:
> > Note I only tested my use case: i.e. same version for the whole
> multimodule
> > project, with sibling "hierarchy", i.e.:
> > * parent-pom (referencing the two submodules with ../projectA and
> > ../projectB)
> > * projectA (with relativePath to ../parent-pom)
> > * projectB
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !
Re: Multimodule release with same version for everything and
dependency version update
Posted by Zac Thompson <za...@gmail.com>.
Baptiste, it seems like you and I are trying to do very similar
things. I have just got back to my efforts in this area, and I am
blocked by an issue that sounds very similar to yours. I just found
it in the following:
http://jira.codehaus.org/browse/MNG-3023
It seems that the multi-module update-everything release-plugin
approach is really only viable for Maven 2.1.0 or above (unless you
want to always have all the snapshots installed before you release)
On Mon, May 4, 2009 at 1:26 AM, Baptiste MATHUS <ml...@batmat.net> wrote:
> Note I only tested my use case: i.e. same version for the whole multimodule
> project, with sibling "hierarchy", i.e.:
> * parent-pom (referencing the two submodules with ../projectA and
> ../projectB)
> * projectA (with relativePath to ../parent-pom)
> * projectB
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Multimodule release with same version for everything and
dependency version update
Posted by Baptiste MATHUS <ml...@batmat.net>.
Well, not so good in the end. For the record, here is a summary of the
things I've discovered so far (I guess some could be listed in the FAQ,
btw). These come from my personal testing. So, if some of the statements
below are know in your opinion, please let me know.
Note I only tested my use case: i.e. same version for the whole multimodule
project, with sibling "hierarchy", i.e.:
* parent-pom (referencing the two submodules with ../projectA and
../projectB)
* projectA (with relativePath to ../parent-pom)
* projectB
Results:
* release:prepare won't be able to to complete successfullu without
-DpreparationGoals="clean install". In fact, contrary to classical "mvn
clean verify" on the multimodule hierarchy, in the context of
release:prepare it seems unable to find it in the reactor. Btw, I found some
blog about this on the web.
* the release-plugin does not support non hierarchical multi-module project
like described above. Actually, it will only tag the project root, and not
be able to find the sub-modules tags when trying to release:perform. I
perfectly understand the complexity behind this (how to find the tagBase of
the subModule if not tagged in the same place...). But I just think this
limitation should be reminded more clearly in the project FAQ. Maybe it
should be (if not already) said somewhere in the doc that non-hierarchical
multimodule project can be problematic, if not unfeasible, to release via
the release-plugin.
* Apart from this blocker limitation, auto-versioning the whole tree seems
to work fine using ${project.version} and -DautoVersionSubmodules=true.
To conclude, I think I'm going to refactor my project so that it becomes a
real hierarchy to be able to use the maven-release-plugin in its supported
use case.
If you have any advice or thought about this subject, I'll be glad to hear
about it.
Cheers.
2009/4/30 Baptiste MATHUS <ml...@batmat.net>
> 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 <ml...@batmat.net>
>
> 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 <li...@gmail.com>
>>
>> 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 <ml...@batmat.net> 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 !
>
--
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !
Re: Multimodule release with same version for everything and
dependency version update
Posted by Baptiste MATHUS <ml...@batmat.net>.
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 <ml...@batmat.net>
> 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 <li...@gmail.com>
>
> 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 <ml...@batmat.net> 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 !
Re: Multimodule release with same version for everything and
dependency version update
Posted by Baptiste MATHUS <ml...@batmat.net>.
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 <li...@gmail.com>
> 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 <ml...@batmat.net> 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 !
Re: Multimodule release with same version for everything and
dependency version update
Posted by Jasper de Vries <li...@gmail.com>.
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 <ml...@batmat.net> 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 !
>