maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jhumble <>
Subject Re: Continuous Delivery and Maven
Date Mon, 08 Nov 2010 04:41:02 GMT

Hi Curtis

I'm the first to admit I'm no Maven expert.

So please let me just confirm. Let's assume I am working on project A which
depends on projects B and C. For the sake of argument, let's say that the
source code for A, B and C have separate roots in SVN, and are usually
checked out independently. The CI system builds A at version 50 using
snapshot dependencies on B and C, which are fetched from a central snapshot

Later, there are multiple updates to projects B and C which result in new
versions of them becoming available.

Say I now check out the source code to project A to version 50, because I
want to try and debug some issue that cropped up in a performance testing
environment, and I run a maven build. Will that use the latest versions of
the snapshots from the repo, or the versions that were originally fetched
when it was run on the CI system?

Can I even find out exactly which versions from svn the snapshots of B and C
came from that were used by the CI system to generate the original build of



On 7 November 2010 20:10, Yanko, Curtis [via Maven] <<>
> wrote:

> Very interesting discussion. With all due respect to Mr. Humble, and I
> am a big fan of CD, I am going to venture to say that you don't
> understand Maven very well. As a thought experiment, you are correct in
> saying that a build based on snapshots is not reproducible. As a more
> practical matter however, I feel it is.
> Dependencies come in two flavors, our and theirs (internal and 3rd
> party). If, all of *our* dependencies are SNAPSHOT (we're doing the
> developing) and all of *theirs* are 'versioned' then the build is in
> fact reproducible assuming you build everything from a particular repo
> version even with the default auto-update setting (in fact, it's
> required).
> ________________________________
> Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
> Making IT Happen, one build at a time, 600 times a day
> -----Original Message-----
> From: jhumble [mailto:[hidden email]<http://user/SendEmail.jtp?type=node&node=3254520&i=0>]
> Sent: Sunday, November 07, 2010 11:15 AM
> To: [hidden email] <http://user/SendEmail.jtp?type=node&node=3254520&i=1>
> Subject: RE: Continuous Delivery and Maven
> Hey Todd
> The whole point of continuous delivery is that every check-in creates a
> potential release candidate.
> When you're doing continuous deployment, you could be releasing multiple
> times a day, so you don't bother cutting branches or tagging or any of
> that stuff because of the overhead. I'd rather not get into the
> justification for this process on this thread - but I wrote a book on it
> if you're interested:
> and many other people have
> blogged about it.
> You're right that creating a concrete release for each commit could
> potentially use up a lot of space - but that's fine, you can just delete
> the older ones. What this *does* mean in turn though is that it is
> essential to be able to recreate any given build given the version in
> source control it came from, and this is where Maven falls down.
> Snapshots just aren't suitable because they aren't reproducible: what
> the snapshot looks like depends not only on what versions of the
> dependencies are available at the time the snapshot is created, but also
> what Maven's configuration and plug-ins happen to be at the time you run
> it (assuming Maven is configured to auto-update - the default). I can't
> revert back to a particular revision in version control, run maven, and
> be sure that the artifact it generates is identical to the one it
> created when the commit was initially triggered.
> Ideally what I'd like is for Maven to explicitly support the continuous
> delivery model and provide snapshots that are reproducible. Failing
> that, a guide to configuring Maven so that its binaries are reproducible
> (for example by switching off auto-update, and having sufficient
> metadata stored in pom files and Maven's artifacts repository to know
> what the state of each of the dependencies was at any given time.
> --
> View this message in context:
> p3254090.html
> Sent from the Maven - Users mailing list archive at
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3254520&i=2>
> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3254520&i=3>
> This e-mail, including attachments, may include confidential and/or
> proprietary information, and may be used only by the person or entity
> to which it is addressed. If the reader of this e-mail is not the intended
> recipient or his or her authorized agent, the reader is hereby notified
> that any dissemination, distribution or copying of this e-mail is
> prohibited. If you have received this e-mail in error, please notify the
> sender by replying to this message and delete this e-mail immediately.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3254520&i=4>
> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3254520&i=5>
> ------------------------------
>  View message @
> To unsubscribe from Continuous Delivery and Maven, click here<>.

Jez Humble
Co-author, *Continuous Delivery <>*

View this message in context:
Sent from the Maven - Users mailing list archive at

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