On Jul 2, 2009, at 11:54 PM, Adam Murdoch wrote:
>
>
> Hans Dockter wrote:
>> I have submitted a new feature which allows a configuration to
>> return the dependency files only for a subset of the dependencies
>> belonging to this configuration.
>>
>> configuration.files(someSpec) or with lazy resolving:
>> configuration.fileCollection(someSpec) // I could not come up with
>> a better name than fileCollection. I'm very happy to hear about a
>> better name.
>
> The names need to reflect that you want the files from the
> configuration, filtered to just those required by the specified
> dependencies.
>
> configuration.filter(someSpec)
> configuration.subset(someSpec)
> configuration.forDependencies(someSpec)
>
> I'd be tempted to get rid of the files(someSpec) methods. To me,
> they don't feel like they are worth the weight they add to
> Configuration.
You would usually use the filecollections at configuration time to be
accessed at execution time. The scenario for the files method I have
in mind are some custom tasks with actions that want to do some custom
dependency stuff (e.g. the ide task of the Gradle build).
task myTask << {
<copy> configurations.compile.files(spec) ...
}
I don't feel strong about this but it looks like a pretty typical use
case.
>
> Some places where we should use this method:
> - The code in AntTestNGExecute which goes looking for the testng
> jar. It should get the files for the testng dependency instead.
Yes
> - The groovy configuration. We should merge this into the compile
> configuration, and get the files for the groovy dependency instead.
Yes
> - The 'ide' tasks in our build files.
Yes
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email