On 28/10/2011, at 2:53 AM, Adam Murdoch wrote: > On 20/10/2011, at 8:51 PM, Luke Daley wrote: > >> Following on from previous email… >> >> Why doesn't `gradle dependencies` act like, say, `gradle clean` and invoke >> the task on all sub projects as well? > > It used to, and by doing this on any real project, you end up with pages of > output, with the actual information you're after buried deep in there. Having > it report on just the current project was a cheap solution, but not a > particularly good one. > > I think we want some better way to express what you're interested in, so we > can show more focused information. Two important use cases, I think: > * show me the (compile) classpath of project x, and why each jar is (or is > not) in there > * show me the (compile-time) project dependency graph for every project > reachable from project x > > I'd be tempted to split this into 2 separate tasks.
Sounds good. This still wouldn't have solved my problem though. The Grails project distributes an ivy cache of all it's dependencies as part of its distribution. They do this by copying the relevant configurations from each project use the Copy task etc. There was a dependency showing up in there that they could not figure out where it was coming from, so they needed to see the dependencies for all projects. It's a bit of a corner case, and I think the current behaviour is probably the right thing to do. But, we probably do need a more obvious way to run the dependencies task for a group of tasks at once. I can't think of a good way to do this though. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com
