maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curtis Rueden <>
Subject Re: dependency management across projects
Date Thu, 06 Feb 2014 20:11:38 GMT
Hi Jörg,

> What do you mean with "irreproducible builds"?

I mean that you may build the same source code today, and then again next
week, and the two build results may differ.

With our projects we wanted the certainty that if you checked out *any*
revision from the SCM history, you would still be able to build it in, say,
5 years... at least as long as you use the same versions of the tooling
(Java version etc.).

With a SNAPSHOT parent, that is not guaranteed. You may introduce a change
in the parent that causes a build to fail when it used to succeed, which
makes "bisect" style debugging no longer feasible. That is, if old SCM
revisions no longer build properly due to changes in the parent, you will
no longer be able to perform a binary search through the SCM history to
determine the exact commit which introduced a bug.

> This scheme works well for us now for several years.

Sure, and I'm not dissing it, just pointing out the pros and cons. We
wanted fully reproducible builds, which meant that even our SNAPSHOT
revisions have only release dependencies, including the parent POM
reference. This indeed has some negative consequences, such as needing that
script to bump things for us, rather than everything "Just Working" with no
changes. And you're right that *release* version builds are still
reproducible either way.


On Wed, Feb 5, 2014 at 1:54 AM, Jörg Schaible

> Hi Curtis,
> Curtis Rueden wrote:
> > Hi Jörg,
> >
> >> We use simply "x-SNAPSHOT" for the parent version. That way no
> >> unreleased project has to be touched, it simply uses the "lastest"
> >> SNAPSHOT of the parent. No script required.
> >
> > Yeah, that is very convenient, if you are willing to accept the two-edged
> > sword of irreproducible builds.
> What do you mean with "irreproducible builds"? Definitely, if you project
> relies on a SNAPSHOT parent, it does not matter if you call it 1-SNAPSHOT
> or
> > A breaking change in the parent will break
> > all builds that consume it... but can be fixed just as easily too without
> > touching the downstream projects.
> Well, somebody obviously made the choice for the SNAPSHOT parent ... with
> all consequences.
> > Of course, it's a decision every project has to make for themselves. My
> > projects opted for build reproducibility by using only release linkages
> > (for parent POMs, dependencies and plugins). This has many advantages:
> > e.g., "git bisect" fully works as one might hope, allowing you to
> > resurrect the state of the code even from years prior and still build
> > successfully. The downside is that you must make releases in order to be
> > able to pin to them.
> Once a project is released, you also have a released parent. No surprises
> anymore. And the project can then make its own decision if it creates also
> a
> branch for the parent and rely on e.g. 254.x-SNAPSHOT either for
> maintenance
> releases or further development.
> This scheme works well for us now for several years.
> Cheers,
> Jörg
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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