>> 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.
'dependency' means criteria in this context and may match multiple dependencies. If one wants a specific dependency he can ask for 'jul-to-slf4j' Again above is the simplest implementation :) We're very welcome for suggestions how the command line api should look like and how the matching rules should work Cheers! > > 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 >> >> > -- Szczepan Faber Principal engineer@gradleware Lead@mockito --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
