On 01/11/2011, at 8:54 PM, Adam Murdoch wrote: > On 02/11/2011, at 4:30 AM, Luke Daley wrote: > >> >> 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. > > You can use the project reports plugin for this kind of thing. > > The idea (and maybe a not-very-good-one) is that 'task', 'dependencies', > 'projects' and 'help' are all part of the 'ui' of the command-line client, > and are intended to be used interactively. The project reports plugin is for > doing any kind of automation over the top of these reports. > > It's looking like instead we should be pushing the implicit tasks to behave > more like regular tasks, so that they live in project.tasks rather than > project.implicitTasks and their special behaviour is also available to > regular tasks (eg. you can declare that 'tasks' in the root project implies > 'tasks' in each of the subprojects, so don't both running them).
Right. Somewhat difficult to see the right way forward here. I think we can postpone doing anything until after 1.0 though. If that's the case, do we add a post 1.0 story? Or do we forget about it and what until something else brings this to the surface? So the question is really how we manage things that we know about but are deferring. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com
