buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Toulme <>
Subject Re: More than one version of the artifact on the classpath
Date Mon, 29 Nov 2010 08:06:54 GMT
That's the approach taken by buildr4osgi.

We write all dependencies inside a dependencies.yml file, and create a dependencies function
so projects can do:

compile.with dependencies

OSGi is involving a lot of resolving by itself.

I had created a branch of Buildr to make that work possible for both Maven and OSGi approaches

Personally whitelisting seems like a bad idea - I've been doing a lot of resolving work and
the bottom line is that resolving is an important action item that should be shared across
your team, with everybody using the same versions of everything. It makes your build reproducible
on all development machines. If you don't write down somewhere that your build depends on
an old library, you might have to look for it 2 years for now, through a ClassNotFoundException.

My 0.0.2c.


On Nov 28, 2010, at 1:57 PM, Peter Donald wrote:

>> 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 ?
> With the current state of the maven repos I tend to prefer the
> whitelist approach but I would welcome a task like you described to
> actually generate the whitelist. At the moment, I add a bit of code
> such as;
> puts transitive('com.example:myartifact:jar:1.2.3').collect{|a|a.to_spec}.join("\n")
> so I can receive the list of transitive dependencies for each top
> level artifact. I generally do this with a few that are a PITA to
> track (i.e. hibernate and eclipse based projects). This givens me a
> big list that I can copy into the build file (or build.yaml as I
> usually do) and then filter for my ctual environment/requirements.
>>> 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.
>> -JS
> -- 
> Cheers,
> Peter Donald

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