On Mon, Oct 22, 2012 at 11:24 AM, Szczepan Faber < [email protected]> wrote:
> >> 1. We should come up with reasonable name for the report before 1.3 > >> and also for the command line options that come with this report. The > >> way one can use the report from the command line (current state of > >> things on master): > >> > >> gradle dependencyInsight --include 'com.org:foo' --configuration > 'runtime' > >> > >> Some other ideas: > >> > >> gradle dependencyUsages --of 'com.org:foo' --configuration 'runtime' > >> gradle dependents --of 'com.org:foo' --configuration 'runtime' > >> gradle whichDependency --include 'com.org:foo' --configuration > 'runtime' > >> gradle showDependency --include 'com.org:foo' --configuration 'runtime' > >> gradle dependency --show 'com.org:foo' --configuration 'runtime' > > > > > > I'm wondering whether the singular dependency is the right term > considering > > that we are providing a pattern that may depict multiple dependencies? > > Some time earlier, in the process of tidying the implementation and > keeping things simple I've changed the API of the task so that the > method that selects the dependency criteria is called 'dependency'. > > So in the current master, it is: 'dependencyInsight --dependency foo:bar' > If you say for example --dependency=slf4j it selects slf4j-api and jul-to-slf4j. So we have a singular term dependency which selects multiple dependencies in this case. Hans > > >> 2. Should we make the new report available by default, e.g. as the > >> implicit tasks are at the moment? > > > > > > I think so. > > It is an implicit task atm in master. So this task is visible when one > runs 'gradle tasks'. > > > > >> > >> > >> This would improve the discoverability of the feature before we > >> implement the auto-apply plugins/tasks. There's a slight downside: say > >> we use a different name than 'dependencies' for the task name (which > >> is very likely because it is a different report). Then the new name > >> may clash with a task name already existing in the client build. > > > > > > I would take that risk. > > We solved this problem by making the new task 'implicit'. This way the > name clash problem no longer exists. > > Cheers! > -- > Szczepan Faber > Principal engineer@gradleware > Lead@mockito > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
