You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Marshall Schor <ms...@schor.com> on 2010/09/24 18:23:55 UTC
Multi-module release, converting -SNAPSHOTs to release versions
Hi,
I have a multi-module project, using a *flat* hierarchy.
The top pom I'm running the mvn release:prepare -DdryRun=ture command has a
<modules> section which specifies the submodules.
The top pom and all the poms in the submodules have version numbers 2.3.1-SNAPSHOT.
The top pom has *some* of the submodules also listed as <dependencies>, with the
2.3.1-SNAPSHOT version.
When I run the release:prepare goal, it asks me if I want to "resolve"
snapshots, just for those listed in <dependencies>. I say yes, and select
1:Project Dependencies at the next prompt.
For all dependencies listed in <dependencies> it then asks if I want to "set to
release*; I say yes, and also take the default for the "next" version.
Then it's off and running, and after a while says "BUILD SUCCESS".
It appears to have prepared poms for the top pom that reflect updating for the
release version, OK (the release version of the pom is 2.3.1, without the
-SNAPSHOT, etc.).
But it did not change any poms for the projects built underneath (the ones in
the <modules> section). Also, a submodule's "target/xxx.pom" shows the
-SNAPSHOT version still.
Perhaps I have a mistaken idea hear. I thought that if my multi-module project
had <module> parts with a -SNAPSHOT version, that "releasing" the top-pom would
result in *all* of the modules getting their version updated.
What is the right way to get all these modules released, in one go, with their
versions switched from -SNAPSHOT to the release version?
(Tried using release plugin version 2.0, trying both maven 3.0-beta-1 and
3.0-RC2 - same results.)
-Marshall Schor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Multi-module release, converting -SNAPSHOTs to release versions
Posted by Marshall Schor <ms...@schor.com>.
one more note: Some references I found on the web seemed to indicate that
multi-module releasing would work to update sub-poms, but their examples had
used the aggregator-pom (the one with the <modules>) also as the parent pom. In
our poms, we've separated Parent-Poms from aggregator-poms; so in our case, the
top pom is *not* the parent of any other pom.
Is it required that the aggregator pom also be the parent, for this to work?
-Marshall Schor
On 9/24/2010 12:23 PM, Marshall Schor wrote:
> Hi,
>
> I have a multi-module project, using a *flat* hierarchy.
>
> The top pom I'm running the mvn release:prepare -DdryRun=ture command has a
> <modules> section which specifies the submodules.
>
> The top pom and all the poms in the submodules have version numbers 2.3.1-SNAPSHOT.
> The top pom has *some* of the submodules also listed as <dependencies>, with the
> 2.3.1-SNAPSHOT version.
>
> When I run the release:prepare goal, it asks me if I want to "resolve"
> snapshots, just for those listed in <dependencies>. I say yes, and select
> 1:Project Dependencies at the next prompt.
>
> For all dependencies listed in <dependencies> it then asks if I want to "set to
> release*; I say yes, and also take the default for the "next" version.
>
> Then it's off and running, and after a while says "BUILD SUCCESS".
>
> It appears to have prepared poms for the top pom that reflect updating for the
> release version, OK (the release version of the pom is 2.3.1, without the
> -SNAPSHOT, etc.).
>
> But it did not change any poms for the projects built underneath (the ones in
> the <modules> section). Also, a submodule's "target/xxx.pom" shows the
> -SNAPSHOT version still.
>
> Perhaps I have a mistaken idea hear. I thought that if my multi-module project
> had <module> parts with a -SNAPSHOT version, that "releasing" the top-pom would
> result in *all* of the modules getting their version updated.
>
> What is the right way to get all these modules released, in one go, with their
> versions switched from -SNAPSHOT to the release version?
>
> (Tried using release plugin version 2.0, trying both maven 3.0-beta-1 and
> 3.0-RC2 - same results.)
>
> -Marshall Schor
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Multi-module release, converting -SNAPSHOTs to release versions
Posted by Marshall Schor <ms...@schor.com>.
On 9/27/2010 6:29 AM, Marshall Schor wrote:
> Here's what I think I've learned.
>
> The release plugin operates in an unusual way, in that there are two invocations
> of work, the "outer" invocation, and an "inner" one.
>
> The inner one is evidenced in the output by having output lines to the console
> that have two prefixes:
>
> [INFO] [INFO] message...
>
> The inner one is run with profiles that can be set using the release plugin's
> configuration parameters:
>
> <useReleaseProfile>false</useReleaseProfile>
> <arguments>-Papache-release</arguments>
>
> These settings *do-not* affect the running of the "outer" invocation.
>
> The outer invocation, when passed a multi-module configuration, does a couple of
> interesting things:
>
> 1) it sets itself up so it SKIPS all the module processing. You can see this in
> the build at the end, where it displays a summary of the build steps, and it
> shows all the other modules in the build with a line:
> [INFO] ...name... SKIPPED
Here's how it does that: Each "mojo" (corresponds to a "goal") in the release
plugin which operates this way, is annotated with "@aggregator". See
http://www.sonatype.com/books/mvnref-book/reference/writing-plugins-sect-plugin-descriptor.html
and search for "aggregator".
-Marshall Schor
<http://www.sonatype.com/books/mvnref-book/reference/writing-plugins-sect-plugin-descriptor.html>
> 2) Nevertheless, it uses all the information about all of the projects in the
> Reactor, to walk through all of them, and do various operations on all of them.
> These include manipulating the poms to new versions. (This information is also
> used during release:clean - to clean up all the submodules.)
>
> This is why it is able to find and update inter-dependent sets of modules, at
> -SNAPSHOT levels, and update all of them.
>
> The message "There are still some remaining snapshot dependencies" - comes after
> the inter-dependent set of modules have been processed to update from the
> -SNAPSHOT levels. This the meaning of the word *still*, here.
>
> This message isn't given if all of the -SNAPSHOTs were resolved during the
> processing of all the modules in the Reactor in the "outer" invocation.
>
>
> Maybe one of the implementors of the release plugin can confirm this theory :-).
>
> -Marshall
>
> On 9/26/2010 5:45 AM, Antonio Petrelli wrote:
>> 2010/9/26 Marshall Schor <ms...@schor.com>:
>>> I guess the super-pom turning on apache-release happened after my <profile> in
>>> my top level aggregator project was "processed", maybe... (not sure about this).
>> Mmm... Here it is:
>> https://repository.apache.org/service/local/repositories/releases/content/org/apache/apache/7/apache-7.pom
>> The only relevant thing I see is a different configuration of the deploy plugin:
>> <updateReleaseInfo>true</updateReleaseInfo>
>>
>> Antonio
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
Re: Multi-module release, converting -SNAPSHOTs to release versions
Posted by Marshall Schor <ms...@schor.com>.
Here's what I think I've learned.
The release plugin operates in an unusual way, in that there are two invocations
of work, the "outer" invocation, and an "inner" one.
The inner one is evidenced in the output by having output lines to the console
that have two prefixes:
[INFO] [INFO] message...
The inner one is run with profiles that can be set using the release plugin's
configuration parameters:
<useReleaseProfile>false</useReleaseProfile>
<arguments>-Papache-release</arguments>
These settings *do-not* affect the running of the "outer" invocation.
The outer invocation, when passed a multi-module configuration, does a couple of
interesting things:
1) it sets itself up so it SKIPS all the module processing. You can see this in
the build at the end, where it displays a summary of the build steps, and it
shows all the other modules in the build with a line:
[INFO] ...name... SKIPPED
2) Nevertheless, it uses all the information about all of the projects in the
Reactor, to walk through all of them, and do various operations on all of them.
These include manipulating the poms to new versions. (This information is also
used during release:clean - to clean up all the submodules.)
This is why it is able to find and update inter-dependent sets of modules, at
-SNAPSHOT levels, and update all of them.
The message "There are still some remaining snapshot dependencies" - comes after
the inter-dependent set of modules have been processed to update from the
-SNAPSHOT levels. This the meaning of the word *still*, here.
This message isn't given if all of the -SNAPSHOTs were resolved during the
processing of all the modules in the Reactor in the "outer" invocation.
Maybe one of the implementors of the release plugin can confirm this theory :-).
-Marshall
On 9/26/2010 5:45 AM, Antonio Petrelli wrote:
> 2010/9/26 Marshall Schor <ms...@schor.com>:
>> I guess the super-pom turning on apache-release happened after my <profile> in
>> my top level aggregator project was "processed", maybe... (not sure about this).
> Mmm... Here it is:
> https://repository.apache.org/service/local/repositories/releases/content/org/apache/apache/7/apache-7.pom
> The only relevant thing I see is a different configuration of the deploy plugin:
> <updateReleaseInfo>true</updateReleaseInfo>
>
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Multi-module release, converting -SNAPSHOTs to release versions
Posted by Antonio Petrelli <an...@gmail.com>.
2010/9/26 Marshall Schor <ms...@schor.com>:
> I guess the super-pom turning on apache-release happened after my <profile> in
> my top level aggregator project was "processed", maybe... (not sure about this).
Mmm... Here it is:
https://repository.apache.org/service/local/repositories/releases/content/org/apache/apache/7/apache-7.pom
The only relevant thing I see is a different configuration of the deploy plugin:
<updateReleaseInfo>true</updateReleaseInfo>
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Multi-module release, converting -SNAPSHOTs to release versions
Posted by Marshall Schor <ms...@schor.com>.
I think I've figured out a way around this issue.
I did it by doing a very simple test case, where I had an aggregate project,
with a submodule *not* specifying the aggregate as the parent.
The simple case worked!
So, I then gradually narrowed the differences between my test project and my
real project, until I found the "cause".
The cause was that the <modules> element in my top aggregator pom was inside a
profile with id "apache-release". The super pom chain of all the poms includes
the common Apache pom (org.apache:apache:7), which itself has a profile for
apache-release, and also configures the release plugin to use that profile for
releasing.
The workaround seems to be that I need to specify -Papache-release on my top
level mvn command - then two things happen:
1) I no longer get the message:
There are still some remaining snapshot dependencies.: Do you want to resolve
them now? (yes/no) no: : yes
Dependency type to resolve,: specify the selection number ( 0:All 1:Project
Dependencies 2:Plugins 3:Reports 4:Extensions ): (0/1/2/3) 1: :
Instead, it just proceeds to ask me about the submodules.
2) It finds and processes the submodules, generating the updated poms for those.
I guess the super-pom turning on apache-release happened after my <profile> in
my top level aggregator project was "processed", maybe... (not sure about this).
-Marshall Schor
On 9/25/2010 4:51 AM, Antonio Petrelli wrote:
> 2010/9/24 Marshall Schor <ms...@schor.com>:
>>
>> On 9/24/2010 3:22 PM, Antonio Petrelli wrote:
>>> 2010/9/24 Marshall Schor <ms...@schor.com>:
>>>> Are you saying that the Maven Release plugin, in particular, has the restriction
>>>> that in order for it to work, it the multimodule project has to be the parent?
>>> At this point I really don't know, since I always had modules that
>>> have the container as a parent, never tried in another way.
>>> Just a question: when you run release:prepare, does it ask you
>>> versions for every single module?
>> No, it asks just for versions where I had specified a <dependency> in the top pom.
>> It's as if the release plugin is set up to only work at the top pom, and not run
>> on the modules within (although it does run the build actions on the modules
>> within).
> Ok. Instead if you have child modules with the container pom as
> parent, it asks versions for every module.
>
>> I'm kind of stumped on how to "work around" this.
> Just a shot in the dark, try:
> http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#autoVersionSubmodules
>
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Multi-module release, converting -SNAPSHOTs to release versions
Posted by Antonio Petrelli <an...@gmail.com>.
2010/9/24 Marshall Schor <ms...@schor.com>:
>
>
> On 9/24/2010 3:22 PM, Antonio Petrelli wrote:
>> 2010/9/24 Marshall Schor <ms...@schor.com>:
>>> Are you saying that the Maven Release plugin, in particular, has the restriction
>>> that in order for it to work, it the multimodule project has to be the parent?
>> At this point I really don't know, since I always had modules that
>> have the container as a parent, never tried in another way.
>> Just a question: when you run release:prepare, does it ask you
>> versions for every single module?
>
> No, it asks just for versions where I had specified a <dependency> in the top pom.
> It's as if the release plugin is set up to only work at the top pom, and not run
> on the modules within (although it does run the build actions on the modules
> within).
Ok. Instead if you have child modules with the container pom as
parent, it asks versions for every module.
> I'm kind of stumped on how to "work around" this.
Just a shot in the dark, try:
http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#autoVersionSubmodules
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Multi-module release, converting -SNAPSHOTs to release versions
Posted by Marshall Schor <ms...@schor.com>.
On 9/24/2010 3:22 PM, Antonio Petrelli wrote:
> 2010/9/24 Marshall Schor <ms...@schor.com>:
>> Are you saying that the Maven Release plugin, in particular, has the restriction
>> that in order for it to work, it the multimodule project has to be the parent?
> At this point I really don't know, since I always had modules that
> have the container as a parent, never tried in another way.
> Just a question: when you run release:prepare, does it ask you
> versions for every single module?
No, it asks just for versions where I had specified a <dependency> in the top pom.
It's as if the release plugin is set up to only work at the top pom, and not run
on the modules within (although it does run the build actions on the modules
within).
I see the release plugin is setup to have its execution inherited by child poms
- it has <inheritedByDefault>true</inheritedByDefault> as part of its plugin.xml
configuration. Maybe this is why it gets executed on submodules, if those
submodules declare the aggregating pom as a "parent".
I'm kind of stumped on how to "work around" this. The only thing that comes to
mind is to take the Reactor order for all the submodules, and run mvn release on
each one, separately, and then change the aggregator pom to no longer do
aggregation, but instead, just build the release artifacts (big zips of the
various components), using the already "released" parts.
-Marshall
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Multi-module release, converting -SNAPSHOTs to release versions
Posted by Antonio Petrelli <an...@gmail.com>.
2010/9/24 Marshall Schor <ms...@schor.com>:
> Are you saying that the Maven Release plugin, in particular, has the restriction
> that in order for it to work, it the multimodule project has to be the parent?
At this point I really don't know, since I always had modules that
have the container as a parent, never tried in another way.
Just a question: when you run release:prepare, does it ask you
versions for every single module?
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Multi-module release, converting -SNAPSHOTs to release versions
Posted by Marshall Schor <ms...@schor.com>.
This is interesting!
The example you pointed to indicates in the section
http://maven.apache.org/guides/introduction/introduction-to-the-pom.html#Project_Inheritance_vs_Project_Aggregation
that the <parent> project can serve for refactoring out common configurations
and settings. It also says you can have a multi-module project (which it also
calls a "parent" project - but I think this is quite confusing, and prefer to
use the term "aggregation" or multi-module project) which specifies the modules
to be built together.
It then says that these two POMs, "can" be the same, which is not the same of
course as saying they *must* be the same.
This reference (from the Maven - the Complete Reference book),
http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-best-practice.html#pom-relationships-sect-multi-vs-inherit
shows a counter example, where these two POMs are not the same: see 3.6.2.1
Simple Project.
Here, they are using a pom to do "aggregation" for multi-submodules, and each of
those submodules does *not* have that aggregation POM as its parent.
The documentation seems to clearly distinguish "parent-poms" referred to using
the <parent> element in another pom -- used for "factoring out" common things
shared by may child poms -- from "aggregation" or "multimodule project" -
specifying what a build should include.
So, this is how we have structured things. The <parent> element refers to poms
that are holding common factored-out settings, while the pom we use for
building/releasing, is just one that gathers all the different submodules
together. We don't make these the same, because different submodules have
different parents (because different kinds of submodules have differing common
parts factored out into the parent).
As I've said previously, the other parts of Maven operation (building,
installing, etc.) seem to work just fine with this setup.
Are you saying that the Maven Release plugin, in particular, has the restriction
that in order for it to work, it the multimodule project has to be the parent?
-Marshall Schor
On 9/24/2010 2:24 PM, Antonio Petrelli wrote:
> 2010/9/24 Marshall Schor <ms...@schor.com>:
>> On 9/24/2010 2:08 PM, Antonio Petrelli wrote:
>>> 2010/9/24 Marshall Schor <ms...@schor.com>:
>>>> The top pom and all the poms in the submodules have version numbers 2.3.1-SNAPSHOT.
>>>> The top pom has *some* of the submodules also listed as <dependencies>, with the
>>>> 2.3.1-SNAPSHOT version.
>>> This does not make any sense, this is a circular dependency,
>> Can you please help explain where the "circularity" comes in? Are you assuming
>> that the sub-modules have a reference to the top pom? (Maybe you assumed they
>> used the top pom as a parent? - but they don't).
> They don't? It's wrong then:
> http://docs.codehaus.org/display/MAVENUSER/Multi-modules+projects
>
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Multi-module release, converting -SNAPSHOTs to release versions
Posted by Antonio Petrelli <an...@gmail.com>.
2010/9/24 Marshall Schor <ms...@schor.com>:
> On 9/24/2010 2:08 PM, Antonio Petrelli wrote:
>> 2010/9/24 Marshall Schor <ms...@schor.com>:
>>> The top pom and all the poms in the submodules have version numbers 2.3.1-SNAPSHOT.
>>> The top pom has *some* of the submodules also listed as <dependencies>, with the
>>> 2.3.1-SNAPSHOT version.
>> This does not make any sense, this is a circular dependency,
>
> Can you please help explain where the "circularity" comes in? Are you assuming
> that the sub-modules have a reference to the top pom? (Maybe you assumed they
> used the top pom as a parent? - but they don't).
They don't? It's wrong then:
http://docs.codehaus.org/display/MAVENUSER/Multi-modules+projects
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Multi-module release, converting -SNAPSHOTs to release versions
Posted by Marshall Schor <ms...@schor.com>.
On 9/24/2010 2:08 PM, Antonio Petrelli wrote:
> 2010/9/24 Marshall Schor <ms...@schor.com>:
>> The top pom and all the poms in the submodules have version numbers 2.3.1-SNAPSHOT.
>> The top pom has *some* of the submodules also listed as <dependencies>, with the
>> 2.3.1-SNAPSHOT version.
> This does not make any sense, this is a circular dependency,
Can you please help explain where the "circularity" comes in? Are you assuming
that the sub-modules have a reference to the top pom? (Maybe you assumed they
used the top pom as a parent? - but they don't).
> and a pom
> project usually (I'd say *always*) does not need dependencies at all.
Yes, in this case, I think you're right, and I could remove these dependencies
in the top pom. (They were put in at one point I think when we were
contemplating an alternative release strategy). But I don't think that would
change my outcome (see below).
> I suspect that one ore more modules depend on others.
They do. They have inter-module dependencies. They build just fine. The
release:prepare does invoke a build of all the submodules, and they all build OK.
The only thing that doesn't seem to be happening is the updating of the pom
versions on those subprojects, which I (maybe incorrectly) assumed the release
plugin would do. It does update the versions ok on the top pom (only).
Thanks for your help.
-Marshall Schor
> You have to add
> dependencies to those modules, not in the pom project.
>
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Multi-module release, converting -SNAPSHOTs to release versions
Posted by Antonio Petrelli <an...@gmail.com>.
2010/9/24 Marshall Schor <ms...@schor.com>:
> The top pom and all the poms in the submodules have version numbers 2.3.1-SNAPSHOT.
> The top pom has *some* of the submodules also listed as <dependencies>, with the
> 2.3.1-SNAPSHOT version.
This does not make any sense, this is a circular dependency, and a pom
project usually (I'd say *always*) does not need dependencies at all.
I suspect that one ore more modules depend on others. You have to add
dependencies to those modules, not in the pom project.
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org