- 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.
Cheers,
Rotsch
2013/5/2 Mirko Friedenhagen <mfriedenha...@gmail.com>
> 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" <rfscho...@apache.org> 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 <
> > minf...@sharp.fm>:
> >
> > On 30 Apr 2013, at 11:21 PM, Roger Brechbühl <rotscher...@gmail.com>
> >> 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*
> >>>
> >>> https://github.com/rotscher/**emerging/tree/version.**
> >>> override-with_maven_install-2.**4<
> https://github.com/rotscher/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.**apache.org<
> users-unsubscr...@maven.apache.org>
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>
