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:
org.springframework:spring-web:jar:3.0.1.RELEASE
SPRING_WEB = [
"activation:activation:jar:1.0.2",
"aopalliance:aopalliance:jar:1.0",
"commons-logging:commons-logging:jar:1.1.1",
"javax.portlet:portlet-api:jar:2.0",
"javax.servlet.jsp:jsp-api:jar:2.1",
"javax.servlet:servlet-api:jar:2.5",
"javax.xml.soap:saaj-api:jar:1.3",
"org.springframework:spring-aop:jar:3.0.1.RELEASE",
"org.springframework:spring-asm:jar:3.0.1.RELEASE",
"org.springframework:spring-beans:jar:3.0.1.RELEASE",
"org.springframework:spring-context:jar:3.0.1.RELEASE",
"org.springframework:spring-core:jar:3.0.1.RELEASE",
"org.springframework:spring-expression:jar:3.0.1.RELEASE",
"org.springframework:spring-web:jar:3.0.1.RELEASE"
]
Completed in 0.711s
you can grab it here --
http://github.com/chetan/misc/blob/master/scripts/buildr_tasks/whitelist.rake
Hopefully others will find it useful.
chetan
On Wed, Feb 24, 2010 at 12:52 PM, Alex Boisvert <alex.boisv...@gmail.com> wrote:
> On Wed, Feb 24, 2010 at 8:47 AM, Will Rogers <wjrog...@gmail.com> wrote:
>
>> On Sat, Jan 23, 2010 at 12:25 PM, Alex Boisvert <alex.boisv...@gmail.com>
>> 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
>
