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