Thanks for feedback!
On Mon, Oct 22, 2012 at 7:19 PM, Luke Daley <[email protected]> wrote:
>
> On 01/10/2012, at 10:03 AM, Szczepan Faber wrote:
>
>> Hey guys,
>>
>> I need some feedback about the name of the new dependency report that
>> shows "the usages of each dependency". For more information about the
>> report, including mock-ups, see:
>> https://github.com/gradle/gradle/blob/master/design-docs/dependency-resolution-reporting.md#new-report-shows-usages-of-each-dependency
>>
>> Currently, the report is called "dependencyInsight". That was the
>> first name that I came up with, I'm not particularly happy with it. It
>> suppose to convey that we're 'zooming' into a particular dependency VS
>> showing all. Therefore it the codebase in master, you can already find
>> a task named "depednecyInsight" of type: DependencyInsightReportTask.
>> There's a already some basic command-line support for this report in
>> the master.
>>
>> 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 don't like any of these as much as dependencyInsight, and they are all less
> accurate. I vote for keeping dependencyInsight with the current args.
>
> I like dependencyInsight because it's general. I can see that over time we
> may expand it's functionality to provide more information over and above what
> we have now.
>
> I'd prefer something like configurationInsight to our current “dependencies”.
>
> --
> Luke Daley
> Principal Engineer, Gradleware
> http://gradleware.com
>
>
> ---------------------------------------------------------------------
> 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
