buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Boisvert <>
Subject Re: More than one version of the artifact on the classpath
Date Sun, 28 Nov 2010 01:46:31 GMT
On Sat, Nov 27, 2010 at 4:34 PM, John Shahid <> wrote:

> Hi Alex,
> > Other than the transitive() method which resolves maven2 artifact
> > dependencies, there's no dependency management in the buildr core at the
> > moment.
> Is there anything in the trunk where I can start from ?

No actual code, no.  I have scraps on my laptop where I've started to
integrate Ivy code and persisting state into YAML file to lock and speed up
dependency resolution.  When I have something ready to share, I'll push a
branch out on github.

> If you need this feature today, I would suggest using the Ivy plugin.
> I noticed this plugin last week but didn't find any examples on how to
> use it with buildr, may be I should spend some time to try it out.

You may want to take a look at:
as one example of using Ivy4r.

> Dependency management is slated for our next major version (1.5.0) and I'm
> > hoping we'll have it done in Q1 2011.
> I'm interested on working on this issue. IMHO, without dependency
> management it is very unlikely that buildr will be used in production
> code. Which is sad because I think buildr offers a lot of nice features
> and the lack of dependency management is the only drawback I could find
> so far and it is easy to fix.

The statement that "it is very unlikely that buildr will be used in
production code" is factually disprovable since buildr has already been
adopted and used in production in several environments already.  More so,
Buildr was actually used in production environments at Intalio even before
it was brought to Apache 2 years ago.

This being said, I won't dispute that dependency management is important and
critical to adoption.  What I'll say is that Buildr was developed _without_
automatic/transitive dependency management _by design_.    Dependency
management was a total hell with Maven2 for years before I actually became
more stable.   This isn't just a critique of the software but also how the
software is used by people.

Beyond software bugs and limitations, few people/projects actually take the
time to correctly state their dependencies.  Many projects get published in
public repos with invalid POMs, incorrect dependencies, too strict/lax
version requirements, etc.   On large projects with many dependencies, it's
not uncommon for dependency management to become an anti-feature.   People
spend more time excluding artifacts, adding missing ones, tweaking version
numbers, aliasing artifacts, adding missing repositories, or importing and
patching artifact into private repositories.   This approach is referred to
as "black-listing" because you're essentially managing a list of exceptions.
  And the world is full of exceptions.

Buildr's current approach is often described as "white-listing".  You have
to explicitly add artifacts and all required dependencies.  There's no
hidden surprises, no unexpected change.  Granted, it's more up-front work
and there's no "magical feeling" but in the long term, it entails less work
in my experience (and many others).    With white-listing, builds become
much more deterministic than their back-listing counterparts.   Builds that
work today will work tomorrow.   They don't depend on someone's current
local M2 repo state.   They don't depend on someone's installed list of
(snapshot) plugins, etc.

I hope this provides some background to explain why transitive dependency
management hasn't been implement yet.  We've been meaning to support both
approaches for a long time but many other features have topped automatic
dependency management so far.  It's not a feature we've overlooked.  It's
not a feature we under-appreciate.   From the start, we've been focused on
implementing features that support production build systems and those took
precedence over "nice to have" feature like automatic dependency management.


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