Having the ability to emit separate reports for the different dependency
contexts (compile-time, etc.) is a very good thing, regardless of whether
or not it would have helped in this particular use case.
It would also be cool to have a way to show any dependency at all but
label them in some manner, as 'ls' on UNIX does with the '--classify'
switch (aside: it doesn't need to be a character pre/postfixed to
the dependency name; it could take the form of a column).
Conceptually, we've got a forest of DAGs and we'd like to be able to:
o Start reporting in location x (default: 'compile')
o Proceed {up|down} the DAG (default: down)
o Recursion depth (default: -1 or "full")
o Filters (eg: only show dependencies of type p, d, and q)
o View options (attribute columns to actually show on output)
-Jon
* Luke Daley ([email protected]) [111102 02:22]:
>
> 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
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
