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 <m...@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 <m...@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 <lit...@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 <m...@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 !
