buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chetan Sarva <>
Subject Re: dzone
Date Fri, 26 Feb 2010 19:51:01 GMT
Love the whitelist idea. I just wrote a simple task which takes care
of my needs at least --

$ buildr whitelist[org.springframework:spring-web:jar:3.0.1.RELEASE]
(in /Users/chetan/play/buildr_whitelist, development)

listing all transitive specs for:


Completed in 0.711s

you can grab it here --

Hopefully others will find it useful.


On Wed, Feb 24, 2010 at 12:52 PM, Alex Boisvert <> wrote:
> On Wed, Feb 24, 2010 at 8:47 AM, Will Rogers <> wrote:
>> On Sat, Jan 23, 2010 at 12:25 PM, Alex Boisvert <>
>> wrote:
>> > solid.  Whitelisting dependencies has worked very well for many of us on
>> big
>> > projects and is probably an under-appreciated feature.
>> What does "whitelisting dependencies" mean?
> Whilelisting dependencies means explicitly specifying all dependencies in
> your project.  No guessing game, all dependencies you use and package are in
> plain sight.
> Compare this to a system where you generate a list of dependencies through a
> transitive closure (e.g. specifying a dependency on Tomcat automatically
> gets you Servlet API, Apache Commons logging, and probably 10+ other
> dependencies).   In such a system, you have to "blacklist" dependencies you
> want to exclude, say, you don't use JSP pages so you don't need Jasper
> (which is a JSP engine integrated with Tomcat).
> Transitive dependencies are typically great to get you started quickly but
> often come back to haunt you because the automatically-generated list may
> contain surprises.  For example, if you have multiple transitive roots (e.g.
> Tomcat and Axis2), then you may have conflicts and/or duplicate dependencies
> that may not be detected.   In an ideal world, these kinds of things don't
> happen but ... in reality they happen and either catch you at the least
> opportune moment or turn into long debugging sessions about why this or that
> isn't working as expected.
> I think we're leaning towards support for transitive dependencies that would
> essentially have a manual, separate phase for resolving dependencies and
> then save/freeze the list so it's not regenerated automatically based on
> changing conditions.  Thus making the result easily
> editable/reviewable/auditable when needed.
> alex

View raw message