This is exactly what I needed a couple of weeks ago. I came up with the
same procedure but discovered that the versions plugin doesn't support
unresolving ranges. Is this something that's in the works or it's just
something you wish were there?
Alejandro Endo | Software Designer/Concepteur de logiciels
From: Stephen Connolly <stephen.alan.conno...@gmail.com>
To: Maven Users List <users@maven.apache.org>,
Date: 2013-08-01 04:56 AM
Subject: Re: continuous releasing: versions:set and/or
release:update-version to release an aggregator project
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
>
>
DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
