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 Sun, 07 Nov 2010 18:29:16 GMT

On 7 November 2010 10:02, Brian Topping wrote:

> Does your book discuss ways to get around these issues?

No, it's a patterns / practices book so we don't go into a lot of detail on
the tools because that information tends to go out of date fast. We discuss
Maven a bit at the end of Chapter 13 ("Managing components and
dependencies"), pp375-378

The advice we give is this: "have your CI server produce canonical versions
of each dependency, using the build label as part of the artifact’s version
number, and store these in your organization’s central artifact repoistory.
You can then use Maven’s version quantifiers in your pom file to specify a
range of acceptable versions to use. If you really need to do some
exploratory work on your local machine, you can always edit your pom
definition to temporarily enable snapshots"

This isn't really ideal, partly for the reason you specify: this leads to a
lot of thrashing with the POM file. So I'm interested to see what could be
done to make Maven work better with the CD paradigm, for instance, stug23's

we have a so-called base-pom, which all projects inherit from, that locks
> down all of the Maven plugin versions so that the build is repeatable at a
> later time.

I think you identify the problem exactly right:

If I understand the paradigm, it's not that developers would want to reject
> the latest version of any dependencies, just that the snapshot builds should
> be reproducible

In fact, I'd go further and say we want to encourage people taking the
latest version of dependencies - otherwise you're not doing continuous
integration. But of course we want all of those dependencies in the artifact
repo, not built from scratch on the developer machines, because then it
means firstly wasted time and secondly that everybody is working with
potentially different binaries.

One possibility to get repeatable builds without filling up an artifacts
repository too fast could be to make Maven store the fully qualified pom
files in the artifacts repo and an md5 of the binary but not necessarily the
actual binary. I know artifacts repos already store some of this

That way you could make sure sufficient metadata is publicly available such
that they can be reproduced, without using up loads of disk space. You could
also happily delete older binaries, safe in the knowledge that people could
reproduce them from the metadata in the artifacts repo.

As you can probably tell I'm no Maven maven, but I do want to help in
whatever way I can to make it work well with a continuous delivery process.


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