Op 3-mrt-2010 om 18:56 heeft Alex Boisvert <[email protected]>
het volgende geschreven:\
Personally, I would not use transitive() here at runtime. I would
run
transitive() to obtain the list of new dependencies and explicitly
set the
manually-corrected list,
@dependencies ||= [ "net.sourceforge.cobertura:cobertura:jar:1.9.4",
"log4j:log4j:jar:1.2.9",
"asm:asm:jar:3.0", "asm:asm-tree:jar:2.2.1", "oro:oro:jar:2.0.8"]
The issue I have with this is that it pins you to a specifc version.
The version method provides a mechanism to specify the cobertura
version in the build.yml, however this doesn't work in practice. In
other words if you need a bugfix release of cobertura (which is what
caused us to hit this problem) you either have to monkey-patch the
extension or create a new buildr release. Neither seem like good
solutions...
Independently of the above, I think this would be a worthwhile
improvement
to transitive() ... I think somebody else (Chetan?) had the same
need just a
week ago. My only warning is that it's a slippery slope from
there... you
get into version number comparison issues quickly and there's little
consistency there, or you want to exclude dependencies of another
dependency, ... things like that.
What I had in mind was an optional block that takes the artifact spec
as parameter and returns boolean. A simple artifact filter in other
words. This would then be checked as the dependency graph is
traversed, cutting off the recursion when false is returned. How the
filtering happens is undefined so this would basically push version
comparison stuff to the user of the api ;) Do you think it makes sense
to pass the dependency stack instead of only a single spec?
Pepijn
