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> > > ... > > <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 > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
