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> > ... > <artifactId>B</artifactId> > <version>2.1-SNAPSHOT</version> > </parent> > <artifactId>C</artifactId> > <!-- no version tag --> > </project> > > and in D > > <project> > <parent> > ... > <artifactId>B</artifactId> > <version>2.1-SNAPSHOT</version> > </parent> > <artifactId>D</artifactId> > <version>2.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 <module>B</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 <module>A</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 > > >> 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> > > >> > ... > > >> > <artifactId>foo</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> > > >> > ... > > >> > <artifactId>foo</artifactId> > > >> > <version>1.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> > > >> > ... > > >> > <artifactId>foo</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 > > >> >> -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 > > >> >> > > >> >> > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > >> For additional commands, e-mail: users-h...@maven.apache.org > > >> > > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > >
