Some other nice output formats for the dependency dag besides
full-dependency-prefixed text and indented-dependency text
would be HTML, json & xml.
-Jon
>
>
> 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
>
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
