On 10/07/10 10:52 PM, Chris Beams wrote:
println project.sourceSets.*main*.compileClasspath.class
-> class
org.gradle.api.internal.artifacts.configurations.DefaultConfiguration_Decorated
println project.sourceSets.*test*.compileClasspath.class
-> class org.gradle.api.internal.file.PathResolvingFileCollection
Why would the compileClasspath types be different across the main vs.
test source sets for the same project?
SourceSet.compileClasspath is declared to be of type FileCollection,
which both these classes implement. The fact that they are different is
really an internal implementation detail. For the main source set,
compileClasspath happens to be set to configurations.compile. For the
test source set, compileClasspath happens to be set to
sourceSets.main.classes + configurations.testCompile.
Because compileClasspath is of type FileCollection, it really only
provides access to the files that make up the classpath. However, I
think there are a number of cases where you want to access the classpath
as a collection of dependencies. And it seems like you've found another
such case.
At the moment we're missing this abstraction, which sits somewhere
between FileCollection and Configuration. After the 0.9 release, we plan
to rework this API, to chop up Configuration into a few reusable pieces.
It would then make sense to change the type of
SourceSet.compileClasspath and runtimeClasspath to this
set-of-dependencies/set-of-files abstraction.
In the meantime, you could use configurations.compile and
configurations.testCompile instead of sourceSets.main.compileClasspath
and sourceSets.test.compileClasspath.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
