maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roger Brechbühl <>
Subject Re: Lightweight maven-releases, or an alternative to the maven-release-plugin
Date Thu, 02 May 2013 13:03:21 GMT
- when speaking about "SNAPSHOTs" we should distinguish between
dependencies and what we produce. With a build we produce an artifact which
is either a SNAPSHOT or release according to the version in the pom.xml. A
dependency resolves either to a SNAPSHOT or a released version of another
library. The dependency might be "internal" (modules built within the same
reactor) or "external".
- an external dependency should never be a SNAPSHOT (it makes life easier
anyway ;-), should only be allowed temporarily.
- all modules in our multi module project always have the same version
(e.g. 0.1.0-SNAPSHOT) and dependencies are defined with ${project.version}

When produce artifacts we deploy them to our target environment (e.g.
war-file to app-server, db scripts to database...) and make some tests. All
this stuff is done during the night in an automated way. We have other
stages where we have to deploy a build which has passed this first tests
but normally, this happens some days later. That's why a SNAPSHOT is not
enough as it's hard to track down which SNAPSHOT we can deliver.

In other words: It's important what we produce and less important what's in
it (e.g. SNAPSHOT or not) as we test if it works or not. Don't get me
wrong: we avoid having SNAPSHOT deps and when it goes to production we
don't have SNAPSHOT libs anymore! But during development this is ok.

And that's what we do all the time: during the day we do continuous builds
(mvn clean install) in the night we create an ad-hoc release with "mvn
clean install -Dversion.override=x.y-n" which is virtually changing the
${project.version} in all our pom.xml but not changing anything in our
version control. And if something fails we don't repeat we start a new one.

By the way: The version.override feature has options to let a build fail or
issue a warning when it detects SNAPSHOT deps. This is not documented but
it's there.


2013/5/2 Mirko Friedenhagen <>

> Hello there,
> I. find prepare and perform quite heavyweight my self. After prepare did
> build everything successfully, it throws away everything, just tags the
> source and starts over again during perform.
> prepare already checks with scm means, that there are no modifications and
> in my experience tagging is the most harmless operation in the whole
> process (well, would I still use CVS that could be different).
> So running prepare with prepareGoals set to "-DperformRelease=true clean
> deploy" does what *I* want.
> - checks I have everything in SCM
> - does modify POMs for release.
> - deploys to staging
> - only on success of this tags the sources
> - go back to SNAPSHOT.
> git and svn (when not doing the strange remoteTagging) are capable of
> tagging always.
> Worst thing that might happen: bad stuff in staging for a short time.
> Regards Mirko
> --
> Sent from my mobile
> On May 1, 2013 9:15 PM, "Robert Scholte" <> wrote:
> > Graham, well said.
> >
> > Although the pom.xml is the easiest way to discover the version, it is
> not
> > the best location, since it would require a commit.
> > The solution must be found in a generated file which will be added to the
> > artifact during packaging. Here you could add a timestamp or revision.
> >
> > Robert
> >
> > Op Wed, 01 May 2013 12:44:19 +0200 schreef Graham Leggett <
> >>:
> >
> >  On 30 Apr 2013, at 11:21 PM, Roger Brechbühl <>
> >> wrote:
> >>
> >>  Maybe somebody is interested in how a release could be built in a more
> >>> lightweight and safe way than with the maven-release-plugin. Especially
> >>> recommended for nightly releases.
> >>>
> >>> It's not yet released, but basically fully working:
> >>>
> >>> *mvn clean install -Dversion.override=1.2.3-S-5*
> >>>
> >>>**emerging/tree/version.**
> >>> override-with_maven_install-2.**4<
> >
> >>>
> >>
> >> Maven has a very clear definition of a "release", being an artefact that
> >> can traced back to the precise code via a tag, and a build that can be
> >> repeated. This is as opposed to a snapshot, which has no well defined
> >> origin.
> >>
> >> You might approach this two ways, you might create "nightly snapshots"
> >> and have them deployed somewhere suitable, using "mvn deploy".
> >>
> >> Alternatively if you want to create proper "nightly releases" (in the
> >> maven sense), you could feed a custom version number into the release
> >> plugin to represent your release, but this starts to smell like "that's
> >> what a snapshot is for".
> >>
> >> Regards,
> >> Graham
> >> --
> >>
> >
> > ------------------------------**------------------------------**---------
> > To unsubscribe, e-mail: users-unsubscribe@maven.**<
> > For additional commands, e-mail:
> >
> >

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