buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Shahid <>
Subject Re: More than one version of the artifact on the classpath
Date Sun, 28 Nov 2010 03:12:42 GMT
On Sat, 2010-11-27 at 17:46 -0800, Alex Boisvert wrote:
> 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.

That's very helpful, thanks.

> > 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.

You're right, I meant wide adoption. I'm sure lot of people have found
buildr features compelling to use in their production code, but the lack
of dependency management prevents buildr from being a drop-in
replacement for maven or ivy; Both of which are widely used in
production. Even for new projects it is a tedious process to trace
through tens of dependencies' pom files and creating a white list of

> 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.

I can't disagree on this one, I've been there before.

> 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 disagree. May be a better solution is to have a buildr task that
resolve all transitive dependencies and have a human guide it through
accepting or rejecting dependencies. The result of this task can be a
lock file, something along the lines of what you're doing now (but more
like Gemfile.lock).

Again, managing white list of dependencies is a tedious process; Why do
anyone have to pull pom files see dependencies and remember to update
the white list every time a new dependency is added ?

> 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.

Yes, that was very helpful.

Thank you.


View raw message