On Wed, Mar 3, 2010 at 10:43 AM, Pepijn Van Eeckhoudt < [email protected]> wrote:
> > > 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... Monkey-patching is probably the "best" solution right now. I've started migrating all these artifact requirements to use artifact_ns() such that they are easier to configure, through buildr.yaml or programmatically without monkey-patching. When you run into code that doesn't use artifact_ns(), please open an issue so we clean it up. 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? > Yes, or both ancestors and spec separately. alex
