buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: More than one version of the artifact on the classpath
Date Sun, 28 Nov 2010 21:57:58 GMT
> 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


Peter Donald

View raw message