Mailing-List: contact users-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Users List" <users@maven.apache.org>
Received-SPF: pass (athena.apache.org: domain of
 stephen.alan.connolly@gmail.com designates 74.125.82.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CACzrW9AYqzNab1Q1eniG9ZHvD4pEYA1WLmUSuku-r92=JJjFpA@mail.gmail.com>
References: 
 <CAGkcVSjki-oRNRCm2V4k7Yp09zS7dBzDg9O+rD9JZeWZBbFQNg@mail.gmail.com>
	<51F7DAEE.4000707@artifact-software.com>
	<1375217160473-5766321.post@n5.nabble.com>
	<51F875F9.5060109@artifact-software.com>
	<CAPNPMOGRUH0EHfMjD+zq-9vqD7PG+e+HVe75sHyrBV0UaHWJPg@mail.gmail.com>
	<1375334367452-5766461.post@n5.nabble.com>
	<CA+nPnMzCjY5Nf1hw8GUWvdxn2y+fqNdd_6oRqehhdKD1L42LuA@mail.gmail.com>
	<CACzrW9AcAX4+Z8rLPPm4vXZDuqpdEUo4Hu2Bgz4WPpPaYH5V5Q@mail.gmail.com>
	<CA+nPnMzXP6XJNnR4iPP3UuV=s7=cpKqCFpyO+Q2DZ6VV=Wud0g@mail.gmail.com>
	<CACzrW9DnYG+V_x1L_kjmBmHK8Vburvjus_cJ2Y29ZsKJHYrQOA@mail.gmail.com>
	<CA+nPnMx4X7QSXU5cvNc0n0P-hJBUR3VOO75UfMnh2mTYtHtWQg@mail.gmail.com>
	<CACzrW9AYqzNab1Q1eniG9ZHvD4pEYA1WLmUSuku-r92=JJjFpA@mail.gmail.com>
Date: Thu, 1 Aug 2013 16:25:11 +0100
Message-ID: 
 <CA+nPnMxdAVXhxu44frXeXM315rs9zUYew6rA7yzBGjKzyX36_Q@mail.gmail.com>
Subject: Re: continuous releasing: versions:set and/or release:update-version
 to release an aggregator project
From: Stephen Connolly <stephen.alan.connolly@gmail.com>
To: Maven Users List <users@maven.apache.org>
Content-Type: multipart/alternative; boundary=f46d04426fb2b1e94904e2e47213

--f46d04426fb2b1e94904e2e47213
Content-Type: text/plain; charset=ISO-8859-1

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 <scolebourne@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.connolly@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 <scolebourne@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.connolly@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 <scolebourne@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.connolly@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.urquiza@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-unsubscribe@maven.apache.org
> >> >> >> For additional commands, e-mail: users-help@maven.apache.org
> >> >> >>
> >> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> >> For additional commands, e-mail: users-help@maven.apache.org
> >> >>
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

--f46d04426fb2b1e94904e2e47213--