On 23/07/2011, at 10:38 AM, Adam Murdoch wrote:

> On 23/07/2011, at 2:53 AM, [email protected] wrote:
> 
>>  Branch: refs/heads/master
>>  Home:   https://github.com/gradle/gradle
>> 
>>  Commit: 94f497b6a90e0a3dc1c54364a450378405d42471
>>      
>> https://github.com/gradle/gradle/commit/94f497b6a90e0a3dc1c54364a450378405d42471
>>  Author: Luke Daley <[email protected]>
>>  Date:   2011-07-22 (Fri, 22 Jul 2011)
>> 
>>  Changed paths:
>>    M 
>> subprojects/core/src/main/groovy/org/gradle/api/artifacts/Configuration.java
>>  M 
>> subprojects/core/src/main/groovy/org/gradle/api/internal/artifacts/configurations/DefaultConfiguration.java
>>  M subprojects/core/src/main/groovy/org/gradle/util/WrapUtil.java
>>  M 
>> subprojects/core/src/test/groovy/org/gradle/api/internal/artifacts/configurations/DefaultConfigurationSpec.groovy
>>  M 
>> subprojects/core/src/test/groovy/org/gradle/api/internal/artifacts/configurations/DefaultConfigurationTest.java
>>  M 
>> subprojects/docs/src/samples/userguideOutput/configurationHandlingDependencies.out
>>  M subprojects/signing/src/main/groovy/org/gradle/plugins/signing/Sign.groovy
>>  M 
>> subprojects/signing/src/main/groovy/org/gradle/plugins/signing/SigningSettings.groovy
>> 
>>  Log Message:
>>  -----------
>>  Built on usage of DomainObjectSet with Configuration to simplify it's API 
>> (and keep the dependency/artifact collections live).
> 
> Cool. I think we can tidy up Configuation a bit more:
> 
> * Deprecate getDependencies(type), replace with 
> getDependencies().withType(type)
> * Deprecate getAllDependencies(type), replace with 
> getAllDependencies().withType(type)
> * Deprecate addDependency(dep), replace with getDependencies().add(dep)
> * Deprecate addArtifact(art) and removeArtifact(art), replace with 
> getArtifacts().add(art) and remove(art)

Agreed, I'll do this.

> It also looks like we don't need the CppExecutableContainer or 
> CppLibraryContainer interfaces. Or probably the CppSourceSetContainer or 
> SourceSetContainer interfaces, either.

You're right about the CPP ones.

As for SourceSetContainer, it's only there for backwards compatibility as what 
was add(String[, Closure]) is now create(String[, Closure]) (necessary to due 
to signature clash with java.util.Collection). However, I don't anyone is using 
the source set container .add() method as they will be using the DSL.

Do you think we completely remove SourceSetContainer? Or deprecate it first? 
I'm for removing.
-- 
Luke Daley
Principal Engineer, Gradleware 
http://gradleware.com

Reply via email to