Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
Hi Nestor
The version.override feature is not a plugin it's an extension to the maven
base installation. So,
http://search.maven.org/#artifactdetails|ch.rotscher.maven.core|maven-core-extensions|0.2.0|jarhas
to be installed to your
*MAVEN_HOME/lib/ext*.
The extension is then activated with *-Dversion.override* on the command
line. It changes the version on the fly but only for the current build and
without changing the pom file. There are several strategies on how the
version is generated.
Beware, that the groupId of the root pom is taken into account whether the
version of a module or dependency should be changed to ${version.override}.
E.g. groupId is *com.foo.bar* then all modules/dependencies with
com.foo.bar and com.foo.bar.* are included. In other words the extension
assumes all modules/dependencies with the same base groupId to be in the
same reactor.
Cheers,
Rotsch
Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
On 2 August 2013 06:51, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
On Friday, 2 August 2013, Stephen Colebourne wrote:
I'm trying to argue that that your perception of it being bad practice
is out of place. It is very common for teams to want to have a tree of
modules that are all versioned together with a single version number.
Then they all should have a common parent and use parent version
inheritance.
They do. But its never that simple. Some of the child modules are
public and some are private (of the same public parent). Since the
names of the private ones cannot be exposed in the public area, we
have a separate private aggregator to pull the private and public into
the same reactor where everything works fine.
I have tested the changes, and they replicate the set-aggregated goal
I wrote. I still think a separate goal is clearer to document and use,
but its your plugin. I think you're going to need quite a lot of
documentation to describe what the plugin is supposed to do. For
example, for my use case, only the artifactId needs to be wildcarded.
There is one area where the plugin does not update (nor did set-aggregated):
dependency
groupIdcom.opengamma.platform/groupId
artifactIdog-integration/artifactId
version${og.version}/version
/dependency
Because it is a property, it is not updated. I think this is a separate issue.
Thanks for working on this. Once released it will work effectively
enough for us, with just the one manual ${og.version} property change.
Stephen
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
@Patrick, Thanks for your reply. It has worked like a charm for three years because the team has not done continuous delivery/deployment. Now it is the time to change that and so the need is genuine: To release everything fixing version numbers on the fly with just one command that can be automated in a CI server. -- View this message in context: http://maven.40175.n5.nabble.com/continuous-releasing-versions-set-and-or-release-update-version-to-release-an-aggregator-project-tp5766275p5766589.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
@Stephen, correct. It works only for inheritance. Not for pure aggregation. -- View this message in context: http://maven.40175.n5.nabble.com/continuous-releasing-versions-set-and-or-release-update-version-to-release-an-aggregator-project-tp5766275p5766590.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
How I want this to work is to have versions-maven-plugin have a way to undo versions:resolve-ranges ( http://mojo.codehaus.org/versions-maven-plugin/resolve-ranges-mojo.html) - it would need to ensure that the lower bound of any unresolved range is the resolved version... [see below] We'd need to split preparationGoals in the release plugin... either into preparationGoals + verificationGoals or into initiationGoals + preparationGoals (I favour the latter as it preserves the semantics of preparationGoals... but the first one maps more correctly with what each set should be doing) Then this would become super easy... You develop with version ranges for your dependencies... The release plugin would have initiationGoals = versions:resolve-ranges versions:commit preparationGoals = clean verify completionGoals = versions:unresolve-ranges versions:commit So say your development pom has dependency ... artifactIdfoo/artifactId version[1.0,2.0)/version /dependency and the latest version of foo is 1.2 When you kick off the release, the range gets resolved to dependency ... artifactIdfoo/artifactId version1.2?versions range=[1.0,2.0)?/version /dependency (My current thought is to use an XML PI to stash the old range) Then we invoke Maven again (because Maven doesn't re-read the poms) and do a clean verify to make sure that this all builds Then we tag the release Then we run completionGoals and versions:unresolve-ranges puts the version range back, but upping the lower bound dependency ... artifactIdfoo/artifactId version[1.2,2.0)/version /dependency Maven ups the pom version to next development snapshot and commits the pom That will give you the ability to develop on ranges (which is nice and flexible) but release on pinned versions (which is exactly what you should be doing) If we cannot deliver something like that, then I think we should just drop ranges from the next major version of Maven. On 1 August 2013 06:19, Nestor Urquiza nestor.urqu...@gmail.com wrote: Hi, Let me give more information, I use an aggregator project for war1 project: modules module../jar1/module module../jar2/module module../war-inc/module module../war1/module /modules Another aggregator project for war2 project: modules module../jar1/module module../war-inc/module module../war1/module /modules Notice they both depend on jar1. The jar2 project in fact depends also on jar1. The war-inc project is used to keep common web resources for war1 and war2. We use maven overlay to marge those shared resources in a final war for each project. This is working like a charm. It has been working in fact now for 3 years. However everytime we need a release we need to start updating version unmbers in dependencies, doing prepare, then perform, you know the story. This is great when the team releases every once in a while. This is an issue if you want to release several times a day. About resources needed and so on that is something we are tackling via idempotent scripts so we are literally ready to make sure we increase the version number for all projects at once every time new code is committed to the version control server. We can handle that last part with jenkins, that is not a problem either. The only problem is how can I leverage on an existing tool (without building it myself) that would allow to release all modules from just one command. So back to Roger suggestion I added the version override dependency as per the github project, updated the version tag to point to 0.2.0 and run the below command (including actually the very same example from github): mvn clean install -Dversion.override=1.2.3-RC-5 However none of the modules were changed including no change to the aggregator project either. Roger, have you used this plugin with aggregator projects as I am trying? Could you provide some further guidance? My option is looking more and more like I will need to do something like: foreach module replace module version for each dependency if it is a module replace module version Then find out if mvn:prepare and mvn:perform will work after from the aggregator project releasing all necessary projects correctly. At this point I am already facing another issue. Let us suppose I update my two war multi-pom aggregator projects, all the modules and the dependencies to be version 2.2000.0-SNAPSHOT. I would expect a command line the below to change the version number in all modules to 2.2000.0, tag it preparing it for release as well as setting the next development version to be 2.2000.1-SNAPSHOT for all modules as well. Finally each dependency that is a module itself should also be changed to 2.2000.1-SNAPSHOT. But that does not work either: mvn clean --batch-mode release:prepare -DdryRun=true -DautoVersionSubmodules=true -DreleaseVersion=2.2000.0
Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
I think this is perhaps related to problems I am seeing right now as well. Basically, the versions:set goal is buggy except in the classic case where the hierarchy of aggregation matches the hierarchy of inheritance. See http://jira.codehaus.org/browse/MVERSIONS-131 and http://jira.codehaus.org/browse/MVERSIONS-184 For example, given a tree: A (pom only) - B - C (pom only) - - D - - E where B and C are children of A and D and E are children of C and A aggregates B and C and C aggregates D and E In this case, versions:set plugin will work fine Now consider adding a new root R which aggregates A, but is not the parent of A. If you run versions:set on R it will only update R, and not A/B/C/D/E If you manually set the version of A, and then run versions:set on R, projects R/A/B/D/E will be updated, but not C. (which is pretty weird) The patch in MVERSIONS-131 sounds reasonable. Could it be evaluated? Stephen On 1 August 2013 09:55, Stephen Connolly stephen.alan.conno...@gmail.com wrote: How I want this to work is to have versions-maven-plugin have a way to undo versions:resolve-ranges ( http://mojo.codehaus.org/versions-maven-plugin/resolve-ranges-mojo.html) - it would need to ensure that the lower bound of any unresolved range is the resolved version... [see below] We'd need to split preparationGoals in the release plugin... either into preparationGoals + verificationGoals or into initiationGoals + preparationGoals (I favour the latter as it preserves the semantics of preparationGoals... but the first one maps more correctly with what each set should be doing) Then this would become super easy... You develop with version ranges for your dependencies... The release plugin would have initiationGoals = versions:resolve-ranges versions:commit preparationGoals = clean verify completionGoals = versions:unresolve-ranges versions:commit So say your development pom has dependency ... artifactIdfoo/artifactId version[1.0,2.0)/version /dependency and the latest version of foo is 1.2 When you kick off the release, the range gets resolved to dependency ... artifactIdfoo/artifactId version1.2?versions range=[1.0,2.0)?/version /dependency (My current thought is to use an XML PI to stash the old range) Then we invoke Maven again (because Maven doesn't re-read the poms) and do a clean verify to make sure that this all builds Then we tag the release Then we run completionGoals and versions:unresolve-ranges puts the version range back, but upping the lower bound dependency ... artifactIdfoo/artifactId version[1.2,2.0)/version /dependency Maven ups the pom version to next development snapshot and commits the pom That will give you the ability to develop on ranges (which is nice and flexible) but release on pinned versions (which is exactly what you should be doing) If we cannot deliver something like that, then I think we should just drop ranges from the next major version of Maven. On 1 August 2013 06:19, Nestor Urquiza nestor.urqu...@gmail.com wrote: Hi, Let me give more information, I use an aggregator project for war1 project: modules module../jar1/module module../jar2/module module../war-inc/module module../war1/module /modules Another aggregator project for war2 project: modules module../jar1/module module../war-inc/module module../war1/module /modules Notice they both depend on jar1. The jar2 project in fact depends also on jar1. The war-inc project is used to keep common web resources for war1 and war2. We use maven overlay to marge those shared resources in a final war for each project. This is working like a charm. It has been working in fact now for 3 years. However everytime we need a release we need to start updating version unmbers in dependencies, doing prepare, then perform, you know the story. This is great when the team releases every once in a while. This is an issue if you want to release several times a day. About resources needed and so on that is something we are tackling via idempotent scripts so we are literally ready to make sure we increase the version number for all projects at once every time new code is committed to the version control server. We can handle that last part with jenkins, that is not a problem either. The only problem is how can I leverage on an existing tool (without building it myself) that would allow to release all modules from just one command. So back to Roger suggestion I added the version override dependency as per the github project, updated the version tag to point to 0.2.0 and run the below command (including actually the very same example from github): mvn clean install -Dversion.override=1.2.3-RC-5 However none of the modules were changed including no change to the aggregator project either. Roger, have you used this plugin with aggregator
Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
the correct way I see to handle this is to support wildcards in versions:set, e.g. mvn versions:set -DgroupId=* -DartifactId=* -DoldVersion=* -DnewVersion=1.2-SNAPSHOT which would therefore match not just the invoked project but all projects in the reactor. The changes in MVERSIONS-131 go against the original spirit of the goal (namely you cd to the module you want to change and ask for it to be changed... the effective reactor is grown and all references down-stream of that module's version change are updated accordingly. If C does not have a parent effected by the change you are making then C should not be changed by versions:set (without wildcard support) On 1 August 2013 13:25, Stephen Colebourne scolebou...@joda.org wrote: I think this is perhaps related to problems I am seeing right now as well. Basically, the versions:set goal is buggy except in the classic case where the hierarchy of aggregation matches the hierarchy of inheritance. See http://jira.codehaus.org/browse/MVERSIONS-131 and http://jira.codehaus.org/browse/MVERSIONS-184 For example, given a tree: A (pom only) - B - C (pom only) - - D - - E where B and C are children of A and D and E are children of C and A aggregates B and C and C aggregates D and E In this case, versions:set plugin will work fine Now consider adding a new root R which aggregates A, but is not the parent of A. If you run versions:set on R it will only update R, and not A/B/C/D/E If you manually set the version of A, and then run versions:set on R, projects R/A/B/D/E will be updated, but not C. (which is pretty weird) The patch in MVERSIONS-131 sounds reasonable. Could it be evaluated? Stephen On 1 August 2013 09:55, Stephen Connolly stephen.alan.conno...@gmail.com wrote: How I want this to work is to have versions-maven-plugin have a way to undo versions:resolve-ranges ( http://mojo.codehaus.org/versions-maven-plugin/resolve-ranges-mojo.html) - it would need to ensure that the lower bound of any unresolved range is the resolved version... [see below] We'd need to split preparationGoals in the release plugin... either into preparationGoals + verificationGoals or into initiationGoals + preparationGoals (I favour the latter as it preserves the semantics of preparationGoals... but the first one maps more correctly with what each set should be doing) Then this would become super easy... You develop with version ranges for your dependencies... The release plugin would have initiationGoals = versions:resolve-ranges versions:commit preparationGoals = clean verify completionGoals = versions:unresolve-ranges versions:commit So say your development pom has dependency ... artifactIdfoo/artifactId version[1.0,2.0)/version /dependency and the latest version of foo is 1.2 When you kick off the release, the range gets resolved to dependency ... artifactIdfoo/artifactId version1.2?versions range=[1.0,2.0)?/version /dependency (My current thought is to use an XML PI to stash the old range) Then we invoke Maven again (because Maven doesn't re-read the poms) and do a clean verify to make sure that this all builds Then we tag the release Then we run completionGoals and versions:unresolve-ranges puts the version range back, but upping the lower bound dependency ... artifactIdfoo/artifactId version[1.2,2.0)/version /dependency Maven ups the pom version to next development snapshot and commits the pom That will give you the ability to develop on ranges (which is nice and flexible) but release on pinned versions (which is exactly what you should be doing) If we cannot deliver something like that, then I think we should just drop ranges from the next major version of Maven. On 1 August 2013 06:19, Nestor Urquiza nestor.urqu...@gmail.com wrote: Hi, Let me give more information, I use an aggregator project for war1 project: modules module../jar1/module module../jar2/module module../war-inc/module module../war1/module /modules Another aggregator project for war2 project: modules module../jar1/module module../war-inc/module module../war1/module /modules Notice they both depend on jar1. The jar2 project in fact depends also on jar1. The war-inc project is used to keep common web resources for war1 and war2. We use maven overlay to marge those shared resources in a final war for each project. This is working like a charm. It has been working in fact now for 3 years. However everytime we need a release we need to start updating version unmbers in dependencies, doing prepare, then perform, you know the story. This is great when the team releases every once in a while. This is an issue if you want to release several times a day. About resources needed
Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
On 01/08/13 01:19 AM, Nestor Urquiza wrote: Hi, Let me give more information, I use an aggregator project for war1 project: modules module../jar1/module module../jar2/module module../war-inc/module module../war1/module /modules Another aggregator project for war2 project: modules module../jar1/module module../war-inc/module module../war1/module /modules Notice they both depend on jar1. The jar2 project in fact depends also on jar1. The war-inc project is used to keep common web resources for war1 and war2. We use maven overlay to marge those shared resources in a final war for each project. From my point of view, this is not dependency, this is inclusion. Assuming that : jar1 and jar2 are independent projects war-inc is common to all your war projects war1 and war2 are to flavors of your project. Each project/module should move at its own pace. If war1 has a dependency on jar1, when war1 is updated, that person should check in your depot what is the most recent version and update accordingly. You say it worked like a charm for 3 years. Maybe you had a problem that was invisible for 3 years and now becomes apparent because you are increasing the pace of releases. My 2 cents. Patrick - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
The problem is that as it currently stands, the plugin gives the appearance of randomly choosing when to change versions. If you consider the second example, the set goal changes R, A, B, D and E, but not C, despite C being a child of A and in A's aggregator. Its hard to not describe that as a bug. Thus, I'm sure you can see the logic of what it is trying to do, but as a user I just want it to change x to y wherever it sees it in the whole aggregator build. If that needs a separate goal, then so be it. I'm not sure how to proceed. The current plugin is useless for my scenario without a separate script file to manually loop around the structure. Its clearly useless for other people using aggregators. You're wildcard suggestion might be an OK solution, but I'd have no idea to implement it. I simply want a goal that allows a multi-module build, where the modules are versioned in lock-step, to be updated. Is that too much to hope for? Stephen On 1 August 2013 13:50, Stephen Connolly stephen.alan.conno...@gmail.com wrote: the correct way I see to handle this is to support wildcards in versions:set, e.g. mvn versions:set -DgroupId=* -DartifactId=* -DoldVersion=* -DnewVersion=1.2-SNAPSHOT which would therefore match not just the invoked project but all projects in the reactor. The changes in MVERSIONS-131 go against the original spirit of the goal (namely you cd to the module you want to change and ask for it to be changed... the effective reactor is grown and all references down-stream of that module's version change are updated accordingly. If C does not have a parent effected by the change you are making then C should not be changed by versions:set (without wildcard support) On 1 August 2013 13:25, Stephen Colebourne scolebou...@joda.org wrote: I think this is perhaps related to problems I am seeing right now as well. Basically, the versions:set goal is buggy except in the classic case where the hierarchy of aggregation matches the hierarchy of inheritance. See http://jira.codehaus.org/browse/MVERSIONS-131 and http://jira.codehaus.org/browse/MVERSIONS-184 For example, given a tree: A (pom only) - B - C (pom only) - - D - - E where B and C are children of A and D and E are children of C and A aggregates B and C and C aggregates D and E In this case, versions:set plugin will work fine Now consider adding a new root R which aggregates A, but is not the parent of A. If you run versions:set on R it will only update R, and not A/B/C/D/E If you manually set the version of A, and then run versions:set on R, projects R/A/B/D/E will be updated, but not C. (which is pretty weird) The patch in MVERSIONS-131 sounds reasonable. Could it be evaluated? Stephen On 1 August 2013 09:55, Stephen Connolly stephen.alan.conno...@gmail.com wrote: How I want this to work is to have versions-maven-plugin have a way to undo versions:resolve-ranges ( http://mojo.codehaus.org/versions-maven-plugin/resolve-ranges-mojo.html) - it would need to ensure that the lower bound of any unresolved range is the resolved version... [see below] We'd need to split preparationGoals in the release plugin... either into preparationGoals + verificationGoals or into initiationGoals + preparationGoals (I favour the latter as it preserves the semantics of preparationGoals... but the first one maps more correctly with what each set should be doing) Then this would become super easy... You develop with version ranges for your dependencies... The release plugin would have initiationGoals = versions:resolve-ranges versions:commit preparationGoals = clean verify completionGoals = versions:unresolve-ranges versions:commit So say your development pom has dependency ... artifactIdfoo/artifactId version[1.0,2.0)/version /dependency and the latest version of foo is 1.2 When you kick off the release, the range gets resolved to dependency ... artifactIdfoo/artifactId version1.2?versions range=[1.0,2.0)?/version /dependency (My current thought is to use an XML PI to stash the old range) Then we invoke Maven again (because Maven doesn't re-read the poms) and do a clean verify to make sure that this all builds Then we tag the release Then we run completionGoals and versions:unresolve-ranges puts the version range back, but upping the lower bound dependency ... artifactIdfoo/artifactId version[1.2,2.0)/version /dependency Maven ups the pom version to next development snapshot and commits the pom That will give you the ability to develop on ranges (which is nice and flexible) but release on pinned versions (which is exactly what you should be doing) If we cannot deliver something like that, then I think we should just drop ranges from the next major version of Maven. On 1 August 2013 06:19, Nestor Urquiza nestor.urqu...@gmail.com wrote:
Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
first off versions:set is a @aggregator mojo. That means it only operates on the -f specified pom file or the pom file in the working directory. The goal is to update *that one project's version* it is not trying to update other project versions. So if you have A +B |+C |+D +E |+F \G where C and D inherits from B, F inherits from E and depends on C, A is an aggregator with no parent-child relationship and G is a standalone project that depends on F directly Further we have in C project parent ... artifactIdB/artifactId version2.1-SNAPSHOT/version /parent artifactIdC/artifactId !-- no version tag -- /project and in D project parent ... artifactIdB/artifactId version2.1-SNAPSHOT/version /parent artifactIdD/artifactId version2.1-SNAPSHOT/version /project from the root of the project you type $ mvn versions:set -f B/pom.xml -DnewVersion=2.2-SNAPSHOT What happens is that the goal's groupId defaults (as no property was set) to the groupId of B, the artifactId defaults to the artifactId of B, the oldVersion defaults to the current version of B and the plugin starts building up its list of changes. Initial list: 1. B:2.1-SNAPSHOT - B:2.2-SNAPSHOT Now it starts looking to see if it can grow the effective reactor... the parent directory has a pom and the pom has moduleB/module so it can grow the effective reactor adding A and all the modules referenced by A into it's list of poms to check. In A's parent directory there is no pom with a moduleA/module so it stops growing the reactor. It now has the following list of poms to check: A,B,C,D,E,F,G It looks to see what the effect of changing B's version is on that set of poms A - no change B - no new changes C - inherits version from parent = add C to list of changes and start again List of changes: 1. B:2.1-SNAPSHOT - B:2.2-SNAPSHOT 2. C:2.1-SNAPSHOT - C:2.2-SNAPSHOT A - no change B - no new changes C - no new changes D - parent changes, but D also explicitly sets version - leave D's version unchanged E - no change F - dependency on C has changed - update dependency G - no change The list of changes has not been mutated this time, so we now have the complete final models to apply Then the poms get updated. So if you start with everything at 2.1-SNAPSHOT, you will end up with A:2.1-SNAPSHOT B:2.2-SNAPSHOT C:2.2-SNAPSHOT D:2.1-SNAPSHOT E:2.1-SNAPSHOT F:2.1-SNAPSHOT G:2.1-SNAPSHOT *and* the reactor maintains its intra module reationships as the dependencies have been updated. If you want to achieve the same result without the -f or changing working directory, you can tell it the groupId and artifactId of the change to make, e.g. $ mvn -DgroupId=... -DartifactId=B -DoldVersion=2.2-SNAPSHOT -DnewVersion=2.1-SNAPSHOT from the directory with A in it will undo all those changes On 1 August 2013 14:17, Stephen Colebourne scolebou...@joda.org wrote: The problem is that as it currently stands, the plugin gives the appearance of randomly choosing when to change versions. If you consider the second example, the set goal changes R, A, B, D and E, but not C, despite C being a child of A and in A's aggregator. Its hard to not describe that as a bug. Thus, I'm sure you can see the logic of what it is trying to do, but as a user I just want it to change x to y wherever it sees it in the whole aggregator build. If that needs a separate goal, then so be it. I'm not sure how to proceed. The current plugin is useless for my scenario without a separate script file to manually loop around the structure. Its clearly useless for other people using aggregators. You're wildcard suggestion might be an OK solution, but I'd have no idea to implement it. I simply want a goal that allows a multi-module build, where the modules are versioned in lock-step, to be updated. Is that too much to hope for? Stephen On 1 August 2013 13:50, Stephen Connolly stephen.alan.conno...@gmail.com wrote: the correct way I see to handle this is to support wildcards in versions:set, e.g. mvn versions:set -DgroupId=* -DartifactId=* -DoldVersion=* -DnewVersion=1.2-SNAPSHOT which would therefore match not just the invoked project but all projects in the reactor. The changes in MVERSIONS-131 go against the original spirit of the goal (namely you cd to the module you want to change and ask for it to be changed... the effective reactor is grown and all references down-stream of that module's version change are updated accordingly. If C does not have a parent effected by the change you are making then C should not be changed by versions:set (without wildcard support) On 1 August 2013 13:25, Stephen Colebourne scolebou...@joda.org wrote: I think this is perhaps related to problems I am seeing right now as well. Basically, the versions:set goal is buggy except in the classic case where the hierarchy of aggregation matches the hierarchy of inheritance. See
Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
If I understand this correctly, goal is to release 2 wars, which have some jars and some wars in common. And, everything is part of the same multi-module-maven-project. That would be sth like: -pom (all versions are defined only here) |- jar1 |- jar2 (depends on jar1) |- war-inc |- war A (depends on jar1 and overlays war-inc) |- war B (depends on jar2 and overlays war-inc) With such structure and if you're using maven release plugin, both warA and warB will be versioned automatically with each release. My approach is to always release the whole project on the main pom level. If I need to move from my version 1.2.07 to 1.3.00, I just find and replace through the whole project current -SNAPSHOT into 1.3.00-SNAPSHOT (which is defined only in version for the pom and in the parent/version of module poms). On Thu, Aug 1, 2013 at 3:36 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: first off versions:set is a @aggregator mojo. That means it only operates on the -f specified pom file or the pom file in the working directory. The goal is to update *that one project's version* it is not trying to update other project versions. So if you have A +B |+C |+D +E |+F \G where C and D inherits from B, F inherits from E and depends on C, A is an aggregator with no parent-child relationship and G is a standalone project that depends on F directly Further we have in C project parent ... artifactIdB/artifactId version2.1-SNAPSHOT/version /parent artifactIdC/artifactId !-- no version tag -- /project and in D project parent ... artifactIdB/artifactId version2.1-SNAPSHOT/version /parent artifactIdD/artifactId version2.1-SNAPSHOT/version /project from the root of the project you type $ mvn versions:set -f B/pom.xml -DnewVersion=2.2-SNAPSHOT What happens is that the goal's groupId defaults (as no property was set) to the groupId of B, the artifactId defaults to the artifactId of B, the oldVersion defaults to the current version of B and the plugin starts building up its list of changes. Initial list: 1. B:2.1-SNAPSHOT - B:2.2-SNAPSHOT Now it starts looking to see if it can grow the effective reactor... the parent directory has a pom and the pom has moduleB/module so it can grow the effective reactor adding A and all the modules referenced by A into it's list of poms to check. In A's parent directory there is no pom with a moduleA/module so it stops growing the reactor. It now has the following list of poms to check: A,B,C,D,E,F,G It looks to see what the effect of changing B's version is on that set of poms A - no change B - no new changes C - inherits version from parent = add C to list of changes and start again List of changes: 1. B:2.1-SNAPSHOT - B:2.2-SNAPSHOT 2. C:2.1-SNAPSHOT - C:2.2-SNAPSHOT A - no change B - no new changes C - no new changes D - parent changes, but D also explicitly sets version - leave D's version unchanged E - no change F - dependency on C has changed - update dependency G - no change The list of changes has not been mutated this time, so we now have the complete final models to apply Then the poms get updated. So if you start with everything at 2.1-SNAPSHOT, you will end up with A:2.1-SNAPSHOT B:2.2-SNAPSHOT C:2.2-SNAPSHOT D:2.1-SNAPSHOT E:2.1-SNAPSHOT F:2.1-SNAPSHOT G:2.1-SNAPSHOT *and* the reactor maintains its intra module reationships as the dependencies have been updated. If you want to achieve the same result without the -f or changing working directory, you can tell it the groupId and artifactId of the change to make, e.g. $ mvn -DgroupId=... -DartifactId=B -DoldVersion=2.2-SNAPSHOT -DnewVersion=2.1-SNAPSHOT from the directory with A in it will undo all those changes On 1 August 2013 14:17, Stephen Colebourne scolebou...@joda.org wrote: The problem is that as it currently stands, the plugin gives the appearance of randomly choosing when to change versions. If you consider the second example, the set goal changes R, A, B, D and E, but not C, despite C being a child of A and in A's aggregator. Its hard to not describe that as a bug. Thus, I'm sure you can see the logic of what it is trying to do, but as a user I just want it to change x to y wherever it sees it in the whole aggregator build. If that needs a separate goal, then so be it. I'm not sure how to proceed. The current plugin is useless for my scenario without a separate script file to manually loop around the structure. Its clearly useless for other people using aggregators. You're wildcard suggestion might be an OK solution, but I'd have no idea to implement it. I simply want a goal that allows a multi-module build, where the modules are versioned in lock-step, to be updated. Is that too much to hope for? Stephen On 1 August 2013 13:50, Stephen Connolly stephen.alan.conno...@gmail.com wrote: the
Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
Thanks for the detailed description, which I hope your making a web page out of. Here is the current description Sets the current projects version, updating the details of any child modules as necessary. From that I conclude it will set the current project version and any child modules necessary to make it all match. It also says The set goal can be used to update the version of the current module. It will automatically climb up local directories to find the aggregation root. It will automatically update explicitly referenced dependencies Again, the expectation is that it will correctly set all the versions I want it to set. From oldVersion to newVersion. Basically, it seems to be being too clever for its own good. As it is, even a batch script cnanot achieve my goal. I have projects like this: A B C - D - E F where A and B are children of C, but not within the aggregator of C (unlike D and E which are children and are within the aggregator). I have a separate overall aggregator R that runs A, B and C. If I set the version of C, and then try to set the version of A or B, the plugin fails with Project version is inherited from parent. So, I get that I'm trying to use the plugin for something you didn't intend, but there isn't an alternative here that does do what I want, right? So, we really need a new goal - versions:set-aggregated - which sets every matching version within an aggregated pom structure when called from the root. Would you want such a thing included in the versions plugin? Or does it need to be a separate plugin? I have to have something, as the alternative is stupid amounts of manual work. Stephen On 1 August 2013 14:36, Stephen Connolly stephen.alan.conno...@gmail.com wrote: first off versions:set is a @aggregator mojo. That means it only operates on the -f specified pom file or the pom file in the working directory. The goal is to update *that one project's version* it is not trying to update other project versions. So if you have A +B |+C |+D +E |+F \G where C and D inherits from B, F inherits from E and depends on C, A is an aggregator with no parent-child relationship and G is a standalone project that depends on F directly Further we have in C project parent ... artifactIdB/artifactId version2.1-SNAPSHOT/version /parent artifactIdC/artifactId !-- no version tag -- /project and in D project parent ... artifactIdB/artifactId version2.1-SNAPSHOT/version /parent artifactIdD/artifactId version2.1-SNAPSHOT/version /project from the root of the project you type $ mvn versions:set -f B/pom.xml -DnewVersion=2.2-SNAPSHOT What happens is that the goal's groupId defaults (as no property was set) to the groupId of B, the artifactId defaults to the artifactId of B, the oldVersion defaults to the current version of B and the plugin starts building up its list of changes. Initial list: 1. B:2.1-SNAPSHOT - B:2.2-SNAPSHOT Now it starts looking to see if it can grow the effective reactor... the parent directory has a pom and the pom has moduleB/module so it can grow the effective reactor adding A and all the modules referenced by A into it's list of poms to check. In A's parent directory there is no pom with a moduleA/module so it stops growing the reactor. It now has the following list of poms to check: A,B,C,D,E,F,G It looks to see what the effect of changing B's version is on that set of poms A - no change B - no new changes C - inherits version from parent = add C to list of changes and start again List of changes: 1. B:2.1-SNAPSHOT - B:2.2-SNAPSHOT 2. C:2.1-SNAPSHOT - C:2.2-SNAPSHOT A - no change B - no new changes C - no new changes D - parent changes, but D also explicitly sets version - leave D's version unchanged E - no change F - dependency on C has changed - update dependency G - no change The list of changes has not been mutated this time, so we now have the complete final models to apply Then the poms get updated. So if you start with everything at 2.1-SNAPSHOT, you will end up with A:2.1-SNAPSHOT B:2.2-SNAPSHOT C:2.2-SNAPSHOT D:2.1-SNAPSHOT E:2.1-SNAPSHOT F:2.1-SNAPSHOT G:2.1-SNAPSHOT *and* the reactor maintains its intra module reationships as the dependencies have been updated. If you want to achieve the same result without the -f or changing working directory, you can tell it the groupId and artifactId of the change to make, e.g. $ mvn -DgroupId=... -DartifactId=B -DoldVersion=2.2-SNAPSHOT -DnewVersion=2.1-SNAPSHOT from the directory with A in it will undo all those changes On 1 August 2013 14:17, Stephen Colebourne scolebou...@joda.org wrote: The problem is that as it currently stands, the plugin gives the appearance of randomly choosing when to change versions. If you consider the second example, the set goal changes R, A, B, D and E, but not C, despite C being a child of A and in A's aggregator. Its
Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
Please try 2.2-SNAPSHOT It may or may have wildcard support that works and doesn't cause any regressions... I need to write some tests for the wildcard stuff. On 1 August 2013 15:39, Stephen Colebourne scolebou...@joda.org wrote: Thanks for the detailed description, which I hope your making a web page out of. Here is the current description Sets the current projects version, updating the details of any child modules as necessary. From that I conclude it will set the current project version and any child modules necessary to make it all match. It also says The set goal can be used to update the version of the current module. It will automatically climb up local directories to find the aggregation root. It will automatically update explicitly referenced dependencies Again, the expectation is that it will correctly set all the versions I want it to set. From oldVersion to newVersion. Basically, it seems to be being too clever for its own good. As it is, even a batch script cnanot achieve my goal. I have projects like this: A B C - D - E F where A and B are children of C, but not within the aggregator of C (unlike D and E which are children and are within the aggregator). I have a separate overall aggregator R that runs A, B and C. If I set the version of C, and then try to set the version of A or B, the plugin fails with Project version is inherited from parent. So, I get that I'm trying to use the plugin for something you didn't intend, but there isn't an alternative here that does do what I want, right? So, we really need a new goal - versions:set-aggregated - which sets every matching version within an aggregated pom structure when called from the root. Would you want such a thing included in the versions plugin? Or does it need to be a separate plugin? I have to have something, as the alternative is stupid amounts of manual work. Stephen On 1 August 2013 14:36, Stephen Connolly stephen.alan.conno...@gmail.com wrote: first off versions:set is a @aggregator mojo. That means it only operates on the -f specified pom file or the pom file in the working directory. The goal is to update *that one project's version* it is not trying to update other project versions. So if you have A +B |+C |+D +E |+F \G where C and D inherits from B, F inherits from E and depends on C, A is an aggregator with no parent-child relationship and G is a standalone project that depends on F directly Further we have in C project parent ... artifactIdB/artifactId version2.1-SNAPSHOT/version /parent artifactIdC/artifactId !-- no version tag -- /project and in D project parent ... artifactIdB/artifactId version2.1-SNAPSHOT/version /parent artifactIdD/artifactId version2.1-SNAPSHOT/version /project from the root of the project you type $ mvn versions:set -f B/pom.xml -DnewVersion=2.2-SNAPSHOT What happens is that the goal's groupId defaults (as no property was set) to the groupId of B, the artifactId defaults to the artifactId of B, the oldVersion defaults to the current version of B and the plugin starts building up its list of changes. Initial list: 1. B:2.1-SNAPSHOT - B:2.2-SNAPSHOT Now it starts looking to see if it can grow the effective reactor... the parent directory has a pom and the pom has moduleB/module so it can grow the effective reactor adding A and all the modules referenced by A into it's list of poms to check. In A's parent directory there is no pom with a moduleA/module so it stops growing the reactor. It now has the following list of poms to check: A,B,C,D,E,F,G It looks to see what the effect of changing B's version is on that set of poms A - no change B - no new changes C - inherits version from parent = add C to list of changes and start again List of changes: 1. B:2.1-SNAPSHOT - B:2.2-SNAPSHOT 2. C:2.1-SNAPSHOT - C:2.2-SNAPSHOT A - no change B - no new changes C - no new changes D - parent changes, but D also explicitly sets version - leave D's version unchanged E - no change F - dependency on C has changed - update dependency G - no change The list of changes has not been mutated this time, so we now have the complete final models to apply Then the poms get updated. So if you start with everything at 2.1-SNAPSHOT, you will end up with A:2.1-SNAPSHOT B:2.2-SNAPSHOT C:2.2-SNAPSHOT D:2.1-SNAPSHOT E:2.1-SNAPSHOT F:2.1-SNAPSHOT G:2.1-SNAPSHOT *and* the reactor maintains its intra module reationships as the dependencies have been updated. If you want to achieve the same result without the -f or changing working directory, you can tell it the groupId and artifactId of the change to make, e.g. $ mvn -DgroupId=... -DartifactId=B -DoldVersion=2.2-SNAPSHOT -DnewVersion=2.1-SNAPSHOT from the
Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
I pulled svn and tried it, and it didn't work in my case. It didn't even set the root aggregator pom. My set-aggregated goal is here and does work: https://gist.github.com/jodastephen/6133391 Unfortunately, half my test project is private so its hard to describe/publish logs. Stephen On 1 August 2013 16:25, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Please try 2.2-SNAPSHOT It may or may have wildcard support that works and doesn't cause any regressions... I need to write some tests for the wildcard stuff. On 1 August 2013 15:39, Stephen Colebourne scolebou...@joda.org wrote: Thanks for the detailed description, which I hope your making a web page out of. Here is the current description Sets the current projects version, updating the details of any child modules as necessary. From that I conclude it will set the current project version and any child modules necessary to make it all match. It also says The set goal can be used to update the version of the current module. It will automatically climb up local directories to find the aggregation root. It will automatically update explicitly referenced dependencies Again, the expectation is that it will correctly set all the versions I want it to set. From oldVersion to newVersion. Basically, it seems to be being too clever for its own good. As it is, even a batch script cnanot achieve my goal. I have projects like this: A B C - D - E F where A and B are children of C, but not within the aggregator of C (unlike D and E which are children and are within the aggregator). I have a separate overall aggregator R that runs A, B and C. If I set the version of C, and then try to set the version of A or B, the plugin fails with Project version is inherited from parent. So, I get that I'm trying to use the plugin for something you didn't intend, but there isn't an alternative here that does do what I want, right? So, we really need a new goal - versions:set-aggregated - which sets every matching version within an aggregated pom structure when called from the root. Would you want such a thing included in the versions plugin? Or does it need to be a separate plugin? I have to have something, as the alternative is stupid amounts of manual work. Stephen On 1 August 2013 14:36, Stephen Connolly stephen.alan.conno...@gmail.com wrote: first off versions:set is a @aggregator mojo. That means it only operates on the -f specified pom file or the pom file in the working directory. The goal is to update *that one project's version* it is not trying to update other project versions. So if you have A +B |+C |+D +E |+F \G where C and D inherits from B, F inherits from E and depends on C, A is an aggregator with no parent-child relationship and G is a standalone project that depends on F directly Further we have in C project parent ... artifactIdB/artifactId version2.1-SNAPSHOT/version /parent artifactIdC/artifactId !-- no version tag -- /project and in D project parent ... artifactIdB/artifactId version2.1-SNAPSHOT/version /parent artifactIdD/artifactId version2.1-SNAPSHOT/version /project from the root of the project you type $ mvn versions:set -f B/pom.xml -DnewVersion=2.2-SNAPSHOT What happens is that the goal's groupId defaults (as no property was set) to the groupId of B, the artifactId defaults to the artifactId of B, the oldVersion defaults to the current version of B and the plugin starts building up its list of changes. Initial list: 1. B:2.1-SNAPSHOT - B:2.2-SNAPSHOT Now it starts looking to see if it can grow the effective reactor... the parent directory has a pom and the pom has moduleB/module so it can grow the effective reactor adding A and all the modules referenced by A into it's list of poms to check. In A's parent directory there is no pom with a moduleA/module so it stops growing the reactor. It now has the following list of poms to check: A,B,C,D,E,F,G It looks to see what the effect of changing B's version is on that set of poms A - no change B - no new changes C - inherits version from parent = add C to list of changes and start again List of changes: 1. B:2.1-SNAPSHOT - B:2.2-SNAPSHOT 2. C:2.1-SNAPSHOT - C:2.2-SNAPSHOT A - no change B - no new changes C - no new changes D - parent changes, but D also explicitly sets version - leave D's version unchanged E - no change F - dependency on C has changed - update dependency G - no change The list of changes has not been mutated this time, so we now have the complete final models to apply Then the poms get updated. So if you start with everything at 2.1-SNAPSHOT, you will end up with A:2.1-SNAPSHOT B:2.2-SNAPSHOT C:2.2-SNAPSHOT D:2.1-SNAPSHOT E:2.1-SNAPSHOT F:2.1-SNAPSHOT G:2.1-SNAPSHOT
Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
Yeah I need to write some tests... You did use wildcards by the way? ie $ mvn versions:set -DgroupId=\* -DartifactId=\* -DoldVersion=\* -Dversion=... Keep in mind you need to escape the wildcard appropriate for your shell or it will replace with a glob that can never match On Thursday, 1 August 2013, Stephen Colebourne wrote: I pulled svn and tried it, and it didn't work in my case. It didn't even set the root aggregator pom. My set-aggregated goal is here and does work: https://gist.github.com/jodastephen/6133391 Unfortunately, half my test project is private so its hard to describe/publish logs. Stephen On 1 August 2013 16:25, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Please try 2.2-SNAPSHOT It may or may have wildcard support that works and doesn't cause any regressions... I need to write some tests for the wildcard stuff. On 1 August 2013 15:39, Stephen Colebourne scolebou...@joda.org wrote: Thanks for the detailed description, which I hope your making a web page out of. Here is the current description Sets the current projects version, updating the details of any child modules as necessary. From that I conclude it will set the current project version and any child modules necessary to make it all match. It also says The set goal can be used to update the version of the current module. It will automatically climb up local directories to find the aggregation root. It will automatically update explicitly referenced dependencies Again, the expectation is that it will correctly set all the versions I want it to set. From oldVersion to newVersion. Basically, it seems to be being too clever for its own good. As it is, even a batch script cnanot achieve my goal. I have projects like this: A B C - D - E F where A and B are children of C, but not within the aggregator of C (unlike D and E which are children and are within the aggregator). I have a separate overall aggregator R that runs A, B and C. If I set the version of C, and then try to set the version of A or B, the plugin fails with Project version is inherited from parent. So, I get that I'm trying to use the plugin for something you didn't intend, but there isn't an alternative here that does do what I want, right? So, we really need a new goal - versions:set-aggregated - which sets every matching version within an aggregated pom structure when called from the root. Would you want such a thing included in the versions plugin? Or does it need to be a separate plugin? I have to have something, as the alternative is stupid amounts of manual work. Stephen On 1 August 2013 14:36, Stephen Connolly stephen.alan.conno...@gmail.com wrote: first off versions:set is a @aggregator mojo. That means it only operates on the -f specified pom file or the pom file in the working directory. The goal is to update *that one project's version* it is not trying to update other project versions. So if you have A +B |+C |+D +E |+F \G where C and D inherits from B, F inherits from E and depends on C, A is an aggregator with no parent-child relationship and G is a standalone project that depends on F directly Further we have in C project parent ... artifactIdB/artifactId version2.1-SNAPSHOT/version /parent artifactIdC/artifactId !-- no version tag -- /project and in D project parent ... artifactIdB/artifactId version2.1-SNAPSHOT/version /parent artifactIdD/artifactI -- Sent from my phone
Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
No, I didn't use the wildcards (they are very unatural UI for solving what seems like a normal case) With wildcards I got NPE: [ERROR] Failed to execute goal org.codehaus.mojo:versions-maven-plugin:2.2-SNAPS HOT:set (default-cli) on project london-dev: Execution default-cli of goal org.c odehaus.mojo:versions-maven-plugin:2.2-SNAPSHOT:set failed. NullPointerException - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal o rg.codehaus.mojo:versions-maven-plugin:2.2-SNAPSHOT:set (default-cli) on project london-dev: Execution default-cli of goal org.codehaus.mojo:versions-maven-plug in:2.2-SNAPSHOT:set failed. at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:225) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProje ct(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProje ct(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBu ild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(Lifecycl eStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Laun cher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.jav a:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(La uncher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java: 352) Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-c li of goal org.codehaus.mojo:versions-maven-plugin:2.2-SNAPSHOT:set failed. at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(Default BuildPluginManager.java:110) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:209) ... 19 more Caused by: java.lang.NullPointerException at org.codehaus.mojo.versions.SetMojo.applyChange(SetMojo.java:258) at org.codehaus.mojo.versions.SetMojo.execute(SetMojo.java:233) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(Default BuildPluginManager.java:101) ... 20 more Stephen On 1 August 2013 18:25, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Yeah I need to write some tests... You did use wildcards by the way? ie $ mvn versions:set -DgroupId=\* -DartifactId=\* -DoldVersion=\* -Dversion=... Keep in mind you need to escape the wildcard appropriate for your shell or it will replace with a glob that can never match On Thursday, 1 August 2013, Stephen Colebourne wrote: I pulled svn and tried it, and it didn't work in my case. It didn't even set the root aggregator pom. My set-aggregated goal is here and does work: https://gist.github.com/jodastephen/6133391 Unfortunately, half my test project is private so its hard to describe/publish logs. Stephen On 1 August 2013 16:25, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Please try 2.2-SNAPSHOT It may or may have wildcard support that works and doesn't cause any regressions... I need to write some tests for the wildcard stuff. On 1 August 2013 15:39, Stephen Colebourne scolebou...@joda.org wrote: Thanks for the detailed description, which I hope your making a web page out of. Here is the current description Sets the current projects version, updating the details of any child modules as necessary. From that I conclude it will set the current project version and any child modules necessary to make it all match. It also says The set goal can be used to update the version of the current module. It will automatically climb up local directories to find the aggregation root. It will automatically update explicitly referenced dependencies Again, the expectation is that it will correctly set all the versions I want it to set. From oldVersion to newVersion. Basically, it seems to be being too clever for its own good. As it is, even a batch script cnanot achieve my goal. I have
Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
On Thursday, 1 August 2013, Stephen Colebourne wrote: No, I didn't use the wildcards (they are very unatural UI for solving what seems like a normal case) With wildcards I got NPE: I'll have a look [ERROR] Failed to execute goal org.codehaus.mojo:versions-maven-plugin:2.2-SNAPS HOT:set (default-cli) on project london-dev: Execution default-cli of goal org.c odehaus.mojo:versions-maven-plugin:2.2-SNAPSHOT:set failed. NullPointerException - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal o rg.codehaus.mojo:versions-maven-plugin:2.2-SNAPSHOT:set (default-cli) on project london-dev: Execution default-cli of goal org.codehaus.mojo:versions-maven-plug in:2.2-SNAPSHOT:set failed. at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:225) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProje ct(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProje ct(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBu ild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(Lifecycl eStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Laun cher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.jav a:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(La uncher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java: 352) Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-c li of goal org.codehaus.mojo:versions-maven-plugin:2.2-SNAPSHOT:set failed. at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(Default BuildPluginManager.java:110) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:209) ... 19 more Caused by: java.lang.NullPointerException at org.codehaus.mojo.versions.SetMojo.applyChange(SetMojo.java:258) at org.codehaus.mojo.versions.SetMojo.execute(SetMojo.java:233) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(Default BuildPluginManager.java:101) ... 20 more Stephen On 1 August 2013 18:25, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Yeah I need to write some tests... You did use wildcards by the way? ie $ mvn versions:set -DgroupId=\* -DartifactId=\* -DoldVersion=\* -Dversion=... Keep in mind you need to escape the wildcard appropriate for your shell or it will replace with a glob that can never match On Thursday, 1 August 2013, Stephen Colebourne wrote: I pulled svn and tried it, and it didn't work in my case. It didn't even set the root aggregator pom. My set-aggregated goal is here and does work: https://gist.github.com/jodastephen/6133391 Unfortunately, half my test project is private so its hard to describe/publish logs. Stephen On 1 August 2013 16:25, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Please try 2.2-SNAPSHOT It may or may have wildcard support that works and doesn't cause any regressions... I need to write some tests for the wildcard stuff. On 1 August 2013 15:39, Stephen Colebourne scolebou...@joda.org wrote: Thanks for the detailed description, which I hope your making a web page out of. Here is the current description Sets the current projects version, updating the details of any child modules as necessary. From that I conclude it will set the current project version and any child modules necessary to make it all match. It also says The set goal can be used to update the version of the current module. It will automatically climb up local directories to find the aggregation root. It will automatically update explicitly referenced dependencies Again, the expectation is that it will
Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
This is exactly what I needed a couple of weeks ago. I came up with the same procedure but discovered that the versions plugin doesn't support unresolving ranges. Is this something that's in the works or it's just something you wish were there? Alejandro Endo | Software Designer/Concepteur de logiciels From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Users List users@maven.apache.org, Date: 2013-08-01 04:56 AM Subject:Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project How I want this to work is to have versions-maven-plugin have a way to undo versions:resolve-ranges ( http://mojo.codehaus.org/versions-maven-plugin/resolve-ranges-mojo.html) - it would need to ensure that the lower bound of any unresolved range is the resolved version... [see below] We'd need to split preparationGoals in the release plugin... either into preparationGoals + verificationGoals or into initiationGoals + preparationGoals (I favour the latter as it preserves the semantics of preparationGoals... but the first one maps more correctly with what each set should be doing) Then this would become super easy... You develop with version ranges for your dependencies... The release plugin would have initiationGoals = versions:resolve-ranges versions:commit preparationGoals = clean verify completionGoals = versions:unresolve-ranges versions:commit So say your development pom has dependency ... artifactIdfoo/artifactId version[1.0,2.0)/version /dependency and the latest version of foo is 1.2 When you kick off the release, the range gets resolved to dependency ... artifactIdfoo/artifactId version1.2?versions range=[1.0,2.0)?/version /dependency (My current thought is to use an XML PI to stash the old range) Then we invoke Maven again (because Maven doesn't re-read the poms) and do a clean verify to make sure that this all builds Then we tag the release Then we run completionGoals and versions:unresolve-ranges puts the version range back, but upping the lower bound dependency ... artifactIdfoo/artifactId version[1.2,2.0)/version /dependency Maven ups the pom version to next development snapshot and commits the pom That will give you the ability to develop on ranges (which is nice and flexible) but release on pinned versions (which is exactly what you should be doing) If we cannot deliver something like that, then I think we should just drop ranges from the next major version of Maven. On 1 August 2013 06:19, Nestor Urquiza nestor.urqu...@gmail.com wrote: Hi, Let me give more information, I use an aggregator project for war1 project: modules module../jar1/module module../jar2/module module../war-inc/module module../war1/module /modules Another aggregator project for war2 project: modules module../jar1/module module../war-inc/module module../war1/module /modules Notice they both depend on jar1. The jar2 project in fact depends also on jar1. The war-inc project is used to keep common web resources for war1 and war2. We use maven overlay to marge those shared resources in a final war for each project. This is working like a charm. It has been working in fact now for 3 years. However everytime we need a release we need to start updating version unmbers in dependencies, doing prepare, then perform, you know the story. This is great when the team releases every once in a while. This is an issue if you want to release several times a day. About resources needed and so on that is something we are tackling via idempotent scripts so we are literally ready to make sure we increase the version number for all projects at once every time new code is committed to the version control server. We can handle that last part with jenkins, that is not a problem either. The only problem is how can I leverage on an existing tool (without building it myself) that would allow to release all modules from just one command. So back to Roger suggestion I added the version override dependency as per the github project, updated the version tag to point to 0.2.0 and run the below command (including actually the very same example from github): mvn clean install -Dversion.override=1.2.3-RC-5 However none of the modules were changed including no change to the aggregator project either. Roger, have you used this plugin with aggregator projects as I am trying? Could you provide some further guidance? My option is looking more and more like I will need to do something like: foreach module replace module version for each dependency if it is a module replace module version Then find out if mvn:prepare and mvn:perform will work after from the aggregator project releasing all necessary projects correctly. At this point I am already facing another issue. Let us suppose I update my two war
Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
On Thursday, 1 August 2013, wrote: This is exactly what I needed a couple of weeks ago. I came up with the same procedure but discovered that the versions plugin doesn't support unresolving ranges. Is this something that's in the works or it's just something you wish were there? It is something I have been trying to figure out a nice way to do for the past 2-3 years... It's never a high enough priority for me though as I just update the poms and move on. The first blocker is identifying if xml pi is preserved by the rewrite that the release plugin does during prepare... If that isn't preserved we need to fall back to magic comments which is sub- optimal to say the least Alejandro Endo | Software Designer/Concepteur de logiciels From: Stephen Connolly stephen.alan.conno...@gmail.com javascript:; To: Maven Users List users@maven.apache.org javascript:;, Date: 2013-08-01 04:56 AM Subject:Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project How I want this to work is to have versions-maven-plugin have a way to undo versions:resolve-ranges ( http://mojo.codehaus.org/versions-maven-plugin/resolve-ranges-mojo.html) - it would need to ensure that the lower bound of any unresolved range is the resolved version... [see below] We'd need to split preparationGoals in the release plugin... either into preparationGoals + verificationGoals or into initiationGoals + preparationGoals (I favour the latter as it preserves the semantics of preparationGoals... but the first one maps more correctly with what each set should be doing) Then this would become super easy... You develop with version ranges for your dependencies... The release plugin would have initiationGoals = versions:resolve-ranges versions:commit preparationGoals = clean verify completionGoals = versions:unresolve-ranges versions:commit So say your development pom has dependency ... artifactIdfoo/artifactId version[1.0,2.0)/version /dependency and the latest version of foo is 1.2 When you kick off the release, the range gets resolved to dependency ... artifactIdfoo/artifactId version1.2?versions range=[1.0,2.0)?/version /dependency (My current thought is to use an XML PI to stash the old range) Then we invoke Maven again (because Maven doesn't re-read the poms) and do a clean verify to make sure that this all builds Then we tag the release Then we run completionGoals and versions:unresolve-ranges puts the version range back, but upping the lower bound dependency ... artifactIdfoo/artifactId version[1.2,2.0)/version /dependency Maven ups the pom version to next development snapshot and commits the pom That will give you the ability to develop on ranges (which is nice and flexible) but release on pinned versions (which is exactly what you should be doing) If we cannot deliver something like that, then I think we should just drop ranges from the next major version of Maven. On 1 August 2013 06:19, Nestor Urquiza nestor.urqu...@gmail.com wrote: Hi, Let me give more information, I use an aggregator project for war1 project: modules module../jar1/module module../jar2/module module../war-inc/module module../war1/module /modules Another aggregator project for war2 project: modules module../jar1/module module../war-inc/module module../war1/module /modules Notice they both depend on jar1. The jar2 project in fact depends also on jar1. The war-inc project is used to keep common web resources for war1 and war2. We use maven overlay to marge those shared resources in a final war for each project. This is working like a charm. It has been working in fact now for 3 years. However everytime we need a release we need to start updating version unmbers in dependencies, doing prepare, then perform, you know the story. This is great when the team releases every once in a while. This is an issue if you want to release several times a day. About resources needed and so on that is something we are tackling via idempotent scripts so we are literally ready to make sure we increase the version number for all projects at once every time new code is committed to the version control server. We can handle that last part with jenkins, that is not a problem either. The only problem is how can I leverage on an existing tool (without building it myself) that would allow to release all modules from just oneDISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not
Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
Fixed in r18607 and I've redeployed a 2.2-SNAPSHOT I now have test cases and I have verified that there are no regressions. Just have to decide if there is anything else I will add before cutting a release On 1 August 2013 18:54, Stephen Connolly stephen.alan.conno...@gmail.comwrote: On Thursday, 1 August 2013, Stephen Colebourne wrote: No, I didn't use the wildcards (they are very unatural UI for solving what seems like a normal case) With wildcards I got NPE: I'll have a look [ERROR] Failed to execute goal org.codehaus.mojo:versions-maven-plugin:2.2-SNAPS HOT:set (default-cli) on project london-dev: Execution default-cli of goal org.c odehaus.mojo:versions-maven-plugin:2.2-SNAPSHOT:set failed. NullPointerException - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal o rg.codehaus.mojo:versions-maven-plugin:2.2-SNAPSHOT:set (default-cli) on project london-dev: Execution default-cli of goal org.codehaus.mojo:versions-maven-plug in:2.2-SNAPSHOT:set failed. at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:225) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProje ct(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProje ct(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBu ild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(Lifecycl eStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Laun cher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.jav a:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(La uncher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java: 352) Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-c li of goal org.codehaus.mojo:versions-maven-plugin:2.2-SNAPSHOT:set failed. at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(Default BuildPluginManager.java:110) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:209) ... 19 more Caused by: java.lang.NullPointerException at org.codehaus.mojo.versions.SetMojo.applyChange(SetMojo.java:258) at org.codehaus.mojo.versions.SetMojo.execute(SetMojo.java:233) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(Default BuildPluginManager.java:101) ... 20 more Stephen On 1 August 2013 18:25, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Yeah I need to write some tests... You did use wildcards by the way? ie $ mvn versions:set -DgroupId=\* -DartifactId=\* -DoldVersion=\* -Dversion=... Keep in mind you need to escape the wildcard appropriate for your shell or it will replace with a glob that can never match On Thursday, 1 August 2013, Stephen Colebourne wrote: I pulled svn and tried it, and it didn't work in my case. It didn't even set the root aggregator pom. My set-aggregated goal is here and does work: https://gist.github.com/jodastephen/6133391 Unfortunately, half my test project is private so its hard to describe/publish logs. Stephen On 1 August 2013 16:25, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Please try 2.2-SNAPSHOT It may or may have wildcard support that works and doesn't cause any regressions... I need to write some tests for the wildcard stuff. On 1 August 2013 15:39, Stephen Colebourne scolebou...@joda.org wrote: Thanks for the detailed description, which I hope your making a web page out of. Here is the current description Sets the current projects version, updating the details of any child modules as necessary. From that I conclude it will set the current project version and any child modules necessary to make it
Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
I'll try and test it tomorrow. However, I'd encourage you to take a step back and think if the use of three extra arguments to the plugin, which is primarily intended for command line use, is a pleasant UI. I'd also encourage you to consider whether updating a single GAV wherever it is found is really the same concept as updating a tree (potentially with filtering to reduce its scope). Using mvn versions:set-aggregated is a lot more pleasant than mvn versions:set -DgroupId=* -DartifactId=* -Dversion=* particularly when the use cases are pretty different. I don't think I'm asking to throw away today's changes, just to repackage them in a more friendly way. Stephen On 2 August 2013 00:10, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Fixed in r18607 and I've redeployed a 2.2-SNAPSHOT I now have test cases and I have verified that there are no regressions. Just have to decide if there is anything else I will add before cutting a release On 1 August 2013 18:54, Stephen Connolly stephen.alan.conno...@gmail.comwrote: On Thursday, 1 August 2013, Stephen Colebourne wrote: No, I didn't use the wildcards (they are very unatural UI for solving what seems like a normal case) With wildcards I got NPE: I'll have a look [ERROR] Failed to execute goal org.codehaus.mojo:versions-maven-plugin:2.2-SNAPS HOT:set (default-cli) on project london-dev: Execution default-cli of goal org.c odehaus.mojo:versions-maven-plugin:2.2-SNAPSHOT:set failed. NullPointerException - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal o rg.codehaus.mojo:versions-maven-plugin:2.2-SNAPSHOT:set (default-cli) on project london-dev: Execution default-cli of goal org.codehaus.mojo:versions-maven-plug in:2.2-SNAPSHOT:set failed. at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:225) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProje ct(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProje ct(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBu ild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(Lifecycl eStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Laun cher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.jav a:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(La uncher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java: 352) Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-c li of goal org.codehaus.mojo:versions-maven-plugin:2.2-SNAPSHOT:set failed. at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(Default BuildPluginManager.java:110) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:209) ... 19 more Caused by: java.lang.NullPointerException at org.codehaus.mojo.versions.SetMojo.applyChange(SetMojo.java:258) at org.codehaus.mojo.versions.SetMojo.execute(SetMojo.java:233) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(Default BuildPluginManager.java:101) ... 20 more Stephen On 1 August 2013 18:25, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Yeah I need to write some tests... You did use wildcards by the way? ie $ mvn versions:set -DgroupId=\* -DartifactId=\* -DoldVersion=\* -Dversion=... Keep in mind you need to escape the wildcard appropriate for your shell or it will replace with a glob that can never match On Thursday, 1 August 2013, Stephen Colebourne wrote: I pulled svn and tried it, and it didn't work in my case. It didn't even set the root aggregator pom. My set-aggregated goal is here and does work: https://gist.github.com/jodastephen/6133391 Unfortunately,
Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
On Friday, 2 August 2013, Stephen Colebourne wrote:
I'll try and test it tomorrow.
However, I'd encourage you to take a step back and think if the use of
three extra arguments to the plugin, which is primarily intended for
command line use, is a pleasant UI. I'd also encourage you to consider
whether updating a single GAV wherever it is found is really the same
concept as updating a tree (potentially with filtering to reduce its
scope).
Using
mvn versions:set-aggregated
is a lot more pleasant than
mvn versions:set -DgroupId=* -DartifactId=* -Dversion=*
particularly when the use cases are pretty different.
I don't think I'm asking to throw away today's changes, just to
repackage them in a more friendly way.
If you are going to do it on a regular basis you either script it or set up
a profile for doing it and then it's just
$ mvn -Pupdate-versions -DnewVersion=2.1-SNAPSHOT
Or if you want to have the profile auto-activated
$ mvn -Dupdated.version=2.1-SNAPSHOT
Where the profile has a defaultGoal of `validate` and you bind
`versions:set` to that phase and inject all the configured wildcards and
inject newVersion as ${updated.version}
That gives you a very error-proof repeated process.
The use of wildcard-like behaviour is not a good plan, so being slightly
more cumbersome on the CLI is a bonus from my PoV.
I prefer to encourage best practice by making non-best practice harder...
Making it impossible is not a good idea IMHO.
- Stephen
Stephen
On 2 August 2013 00:10, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
Fixed in r18607 and I've redeployed a 2.2-SNAPSHOT
I now have test cases and I have verified that there are no regressions.
Just have to decide if there is anything else I will add before cutting a
release
On 1 August 2013 18:54, Stephen Connolly
stephen.alan.conno...@gmail.comwrote:
On Thursday, 1 August 2013, Stephen Colebourne wrote:
No, I didn't use the wildcards (they are very unatural UI for solving
what seems like a normal case)
With wildcards I got NPE:
I'll have a look
[ERROR] Failed to execute goal
org.codehaus.mojo:versions-maven-plugin:2.2-SNAPS
HOT:set (default-cli) on project london-dev: Execution default-cli of
goal org.c
odehaus.mojo:versions-maven-plugin:2.2-SNAPSHOT:set failed.
NullPointerException
- [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute
goal o
rg.codehaus.mojo:versions-maven-plugin:2.2-SNAPSHOT:set (default-cli)
on
project
london-dev: Execution default-cli of goal
org.codehaus.mojo:versions-maven-plug
in:2.2-SNAPSHOT:set failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor
.java:225)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor
.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor
.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProje
ct(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProje
ct(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBu
ild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(Lifecycl
eStarter.java:161)
at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Laun
cher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.jav
a:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(La
uncher.java:409)
at
org.codehau
--
Sent from my phone
Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
On 2 August 2013 01:10, Stephen Connolly stephen.alan.conno...@gmail.com wrote: The use of wildcard-like behaviour is not a good plan, so being slightly more cumbersome on the CLI is a bonus from my PoV. I prefer to encourage best practice by making non-best practice harder... Making it impossible is not a good idea IMHO. I'm trying to argue that that your perception of it being bad practice is out of place. It is very common for teams to want to have a tree of modules that are all versioned together with a single version number. It is your implementation choice to make it wildcarded. What I, and others, need is to simply replace all matching versions in a single aggregated reactor with a new version. While these two approaches may seem similar, I humbly suggest that they are conceptually different. Stephen - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
On Friday, 2 August 2013, Stephen Colebourne wrote: On 2 August 2013 01:10, Stephen Connolly stephen.alan.conno...@gmail.com javascript:; wrote: The use of wildcard-like behaviour is not a good plan, so being slightly more cumbersome on the CLI is a bonus from my PoV. I prefer to encourage best practice by making non-best practice harder... Making it impossible is not a good idea IMHO. I'm trying to argue that that your perception of it being bad practice is out of place. It is very common for teams to want to have a tree of modules that are all versioned together with a single version number. Then they all should have a common parent and use parent version inheritance. If the version number is supposed to be the same, then you use inheritance from the root and versions:set takes care of it all for you. If the version number is not supposed to be the same, then versions set does exactly what you want also, allowing you to carve version number increments through the entire tree for those portions which are supposed to be the same. It is your implementation choice to make it wildcarded. What I, and others, need is to simply replace all matching versions in a single aggregated reactor with a new version. While these two approaches may seem similar, I humbly suggest that they are conceptually different. Stephen - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: users-h...@maven.apache.orgjavascript:; -- Sent from my phone
Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
don't know exactly how your project setup is, but maybe this approach could help: https://github.com/rotscher/emerging/tree/version.override-with_maven_install-2.4 We use it for an automated continuous delivery process. Please note, that there is a release 0.2.0 available despite what the documentation says. 2013/7/31 Ron Wheeler rwhee...@artifact-software.com On 30/07/2013 4:46 PM, Nestor Urquiza wrote: Ron, Thanks for your feedback. I have been using Maven the same way like you since 2007. However things have changed in our current shop. We want continuous releasing and for that we desperately need to automate versioning. Can you explain how this affects version numbers. We do not need to maintain it manually anymore, any commit is a potential release for us. I am not sure what this means. It is true for some cases depending on what you mean by a commit. We commit a lot of projects to Subversion that are just a set of classes/packages that one programmer has finished but the project may require some more work to complete the changes that need to be done to satisfy all of thegoals of the release. Anybody else? I am trying really hard to stick to Maven as I have been doing for so many years since I departed from ant. This two plugins could resolve the continuous delivery support while still keeping maven as the tool for organizing the project. Perhaps you can add more details about what you are looking for and what alternative solutions would get you back on the road again. Perhaps you can explain how Maven could identify all the projects that need changing if the company is developing or supporting multiple applications. At any time we have 4 or 5 applications that are active in one sense or another and I am sure that big organizations might have 50+ applications under active support or development. Identifying which ones you want to have the same version will require a list somewhere. I hope that these comments help. Ron Thanks! - Nestor -- View this message in context: http://maven.40175.n5.nabble.** com/continuous-releasing-**versions-set-and-or-release-** update-version-to-release-an-**aggregator-project-** tp5766275p5766321.htmlhttp://maven.40175.n5.nabble.com/continuous-releasing-versions-set-and-or-release-update-version-to-release-an-aggregator-project-tp5766275p5766321.html Sent from the Maven - Users mailing list archive at Nabble.com. --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
Hi, Let me give more information, I use an aggregator project for war1 project: modules module../jar1/module module../jar2/module module../war-inc/module module../war1/module /modules Another aggregator project for war2 project: modules module../jar1/module module../war-inc/module module../war1/module /modules Notice they both depend on jar1. The jar2 project in fact depends also on jar1. The war-inc project is used to keep common web resources for war1 and war2. We use maven overlay to marge those shared resources in a final war for each project. This is working like a charm. It has been working in fact now for 3 years. However everytime we need a release we need to start updating version unmbers in dependencies, doing prepare, then perform, you know the story. This is great when the team releases every once in a while. This is an issue if you want to release several times a day. About resources needed and so on that is something we are tackling via idempotent scripts so we are literally ready to make sure we increase the version number for all projects at once every time new code is committed to the version control server. We can handle that last part with jenkins, that is not a problem either. The only problem is how can I leverage on an existing tool (without building it myself) that would allow to release all modules from just one command. So back to Roger suggestion I added the version override dependency as per the github project, updated the version tag to point to 0.2.0 and run the below command (including actually the very same example from github): mvn clean install -Dversion.override=1.2.3-RC-5 However none of the modules were changed including no change to the aggregator project either. Roger, have you used this plugin with aggregator projects as I am trying? Could you provide some further guidance? My option is looking more and more like I will need to do something like: foreach module replace module version for each dependency if it is a module replace module version Then find out if mvn:prepare and mvn:perform will work after from the aggregator project releasing all necessary projects correctly. At this point I am already facing another issue. Let us suppose I update my two war multi-pom aggregator projects, all the modules and the dependencies to be version 2.2000.0-SNAPSHOT. I would expect a command line the below to change the version number in all modules to 2.2000.0, tag it preparing it for release as well as setting the next development version to be 2.2000.1-SNAPSHOT for all modules as well. Finally each dependency that is a module itself should also be changed to 2.2000.1-SNAPSHOT. But that does not work either: mvn clean --batch-mode release:prepare -DdryRun=true -DautoVersionSubmodules=true -DreleaseVersion=2.2000.0 -DdevelopmentVersion=2.2000.1-SNAPSHOT The resulting pom.xml.tag gets updated even dependencies but the pom.xml.next gets updated (2.2000.1-SNAPSHOT) only for the version number of each project, nor for the dependencies which do stay the same (2.2000.0-SNAPSHOT). Will this be considered a bug? I hope it is clear now what I need and also what the current issues are: Not only versions:set and release:update-version do not work for multipom-aggregator projects but in addition release:prepare together with all the flags above which according to the documentation should be allowing to fix a version for a release. I guess an alternative question could be how to provide continuous delivery with multi-pom aggregator maven projects. To be honest I do not like the idea of forcing all versions, it just looked the logical approach after we decided we really did not care for internal versions, they could be handled ideally automatically. However thinking twice about this I would like better maven to accept a pattern to set part of the snapshot version number while changing another part of it, for example with a mask: -DversionNumberIncrementalMask=x.1.0 which would translate to: Leave first digit as is Increase by 1 second digit set to zero third digit Of course I would expect this to be applied to all snapshots. Thanks for the answers so far, - Nestor -- View this message in context: http://maven.40175.n5.nabble.com/continuous-releasing-versions-set-and-or-release-update-version-to-release-an-aggregator-project-tp5766275p5766461.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
Our solution was to stop synchronizing release versions of dependencies. We were perfectly happy using software from third parties (Apache, Spring, etc.) with different versions and ceased to see any reason why version 1.10 of the WAR file could not depend on version 1.8 of one of our jar files if, in fact, 1.8 was the correct code for 1.10 of our release. Once we got over the block in our minds, it worked very well. As a side benefit, we could also quickly see what modules had actually changed in each release. If the jar had a 1.10.x version, then it had changed; if it was 1.9, then the new release had not required a change in that part of the code. We had 80+ projects making up the application so the reduction in workload was appreciated. It also made it easier to understand the scope of a new release since we took an hour at the start of the release cycle and identified the affect expected on each module so that I had a pretty good idea about the work that was going to be required and the number of project tasks that were about to start up. Ron On 30/07/2013 11:10 AM, Nestor Urquiza wrote: Hi guys, We use two aggregator projects to release two WAR applications which have some shared JAR projects. This aggregators are not parents. Strictly speaking the JAR projects do not reference back the aggregators. As a developer I would like to set a release version not only for the aggregator but for all modules it references. It looks like the below command will only change the version for the aggregator project. Apparently the only way to make the modules change their version as well will be to make the aggregator a real parent. This would demand us having really two parents for certain JARS while not for others. Definitely inheritance is not the way to go but aggregation. This command will not fail with an ERROR but the modules will not get updated. pre mvn clean install versions:set -DnewVersion=2.12345678.0 /pre It looks like the below command is not working: pre mvn -U release:update-versions -DdevelopmentVersion=2.12345679.0 /pre As I get: Required goal not found: release:update-versions in org.apache.maven.plugins:maven-release-plugin:2.0-beta-8 I have found some archives about the subject but no real solution to this problem so far. Thanks in advance, - Nestor Urquiza -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
Ron, Thanks for your feedback. I have been using Maven the same way like you since 2007. However things have changed in our current shop. We want continuous releasing and for that we desperately need to automate versioning. We do not need to maintain it manually anymore, any commit is a potential release for us. Anybody else? I am trying really hard to stick to Maven as I have been doing for so many years since I departed from ant. This two plugins could resolve the continuous delivery support while still keeping maven as the tool for organizing the project. Thanks! - Nestor -- View this message in context: http://maven.40175.n5.nabble.com/continuous-releasing-versions-set-and-or-release-update-version-to-release-an-aggregator-project-tp5766275p5766321.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
On 30/07/2013 4:46 PM, Nestor Urquiza wrote: Ron, Thanks for your feedback. I have been using Maven the same way like you since 2007. However things have changed in our current shop. We want continuous releasing and for that we desperately need to automate versioning. Can you explain how this affects version numbers. We do not need to maintain it manually anymore, any commit is a potential release for us. I am not sure what this means. It is true for some cases depending on what you mean by a commit. We commit a lot of projects to Subversion that are just a set of classes/packages that one programmer has finished but the project may require some more work to complete the changes that need to be done to satisfy all of thegoals of the release. Anybody else? I am trying really hard to stick to Maven as I have been doing for so many years since I departed from ant. This two plugins could resolve the continuous delivery support while still keeping maven as the tool for organizing the project. Perhaps you can add more details about what you are looking for and what alternative solutions would get you back on the road again. Perhaps you can explain how Maven could identify all the projects that need changing if the company is developing or supporting multiple applications. At any time we have 4 or 5 applications that are active in one sense or another and I am sure that big organizations might have 50+ applications under active support or development. Identifying which ones you want to have the same version will require a list somewhere. I hope that these comments help. Ron Thanks! - Nestor -- View this message in context: http://maven.40175.n5.nabble.com/continuous-releasing-versions-set-and-or-release-update-version-to-release-an-aggregator-project-tp5766275p5766321.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
