maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
Date Thu, 01 Aug 2013 19:44:45 GMT
On Thursday, 1 August 2013, wrote:

> 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?
>
>
It is something I have been trying to figure out a nice way to do for the
past 2-3 years... It's never a high enough priority for me though as I just
update the poms and move on.

The first blocker is identifying if xml pi is preserved by the rewrite that
the release plugin does during prepare... If that isn't preserved we need
to fall back to "magic" comments which is sub- optimal to say the least


>
> Alejandro Endo | Software Designer/Concepteur de logiciels
>
>
>
>
> From:   Stephen Connolly <stephen.alan.connolly@gmail.com <javascript:;>>
> To:     Maven Users List <users@maven.apache.org <javascript:;>>,
> 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.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 oneDISCLAIMER:
> 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-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: users-help@maven.apache.org<javascript:;>
>
>

-- 
Sent from my phone

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message