New features for configurations

[hdockter]

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.

This is a pretty important feature. The way we have solved this so far  
is to use a copy of the configuration. But in case of version  
conflicts between dependencies of the subset and dependencies not  
contained in the subset, the resolve result of a copy versus the new  
methods is different. As part of this I have changed the way we  
extract the dependency files from ivy. Of course all tests are running  
but I'm keen to get feedback if this has changed the behavior in any  
way.

Currently there is one limitation. Let's say we have the following  
dependencies:

A->B(exclude C)->C
X->C

configuration.files(A) returns: A,C It should be: A

This is because C is part of the configuration. I haven't figured out  
a good way yet to get the right information from Ivy via its public  
API to return the right result.

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Adam Murdoch-2]

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.

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.
- The groovy configuration. We should merge this into the compile
configuration, and get the files for the groovy dependency instead.
- The 'ide' tasks in our build files.



Adam

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[hdockter]

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