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 jodastephen@gmail.com
 designates 209.85.212.49 as permitted sender)
MIME-Version: 1.0
Sender: jodastephen@gmail.com
In-Reply-To: 
 <CA+nPnMzCjY5Nf1hw8GUWvdxn2y+fqNdd_6oRqehhdKD1L42LuA@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>
From: Stephen Colebourne <scolebourne@joda.org>
Date: Thu, 1 Aug 2013 13:25:17 +0100
Message-ID: 
 <CACzrW9AcAX4+Z8rLPPm4vXZDuqpdEUo4Hu2Bgz4WPpPaYH5V5Q@mail.gmail.com>
Subject: Re: continuous releasing: versions:set and/or release:update-version
 to release an aggregator project
To: Maven Users List <users@maven.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

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