On Aug 24, 2009, at 5:24 AM, Adam Murdoch wrote:
Hi,
I've checked in the first pass at introducing source sets. There's
still a ways to go. Here's what we have so far:
To define a source set:
source {
integrationTest
}
For source set 'nnn', default values are:
- java src dirs: [$projectDir/src/nnn/java]
- resource dirs: [$projectDir/src/nnn/resources]
- compile classpath: configurations.compile
- runtime classpath: configurations.runtime
- classes dir: $buildDir/classes/nnn
When a source set 'nnn' is added, the following tasks are added:
- compileNnn
- processNnnResources
The Java plugin adds 2 source sets by default, so that we keep the
behaviour we used to have:
- main
- test
You can configure a source set in the same ways you configure other
domain objects:
source {
main {
java {
srcDirs = ['src/java/main']
include 'org/gradle/**'
}
resources {
srcDir 'src/resources/main'
...
}
}
source.main.java.srcDirs = ['src/java/main']
Some more examples at
http://docs.codehaus.org/display/GRADLE/Gradle+0.8+Breaking+Changes
The 'source' property is a SourceSetContainer instance. Each source
set is a SourceSet.
Some issues, things to do, questions:
- Only works for java source and resources so far. I will add groovy
and scala source.
- Eclipse plugin and code quality plugins don't do anything when a
source set is added. They should understand source sets.
- The includes and excludes defined on the source set are only used
by the checkstyle and codenarc tasks so far. They need to be wired
up for all tasks which understand source.
- The compile and processResources tasks of the main source set
don't follow the naming scheme we use for the other source sets.
Should we rename them to compileMain and processMainResources?
Good question. I think we should have both. The JavaPlugin should
create an alias compile and processResources pointing to compileMain
and processMainResources. Which make me think of we shouldn't
explicitly support aliases for task names (vs. creating a new task
that depends on another task)?
- Should we automatically add a jar, javadoc, groovydoc, etc, task
for each source set? Or a rule, where jarNnn adds a synthetic Jar
task which jars up the classes from the source set?
The disadvantage of automatically adding those tasks is that this
produces noise in gradle -t. You will use SourceSet's in ways were
some of the tasks above are irrelevant. If we go for rules, we can
still let the SourceSet API have task returning methods like getJar(),
getJavadoc(), .... But the actual tasks would be added only on demand.
You could even argue that, though unlikely, a compile task is not
always needed. So me might even add the compile task via rules. That
would make things consistent.
On the other hand, I'm not sure if the noise above really is a problem.
Should gradle -t also list the source set's? If we go for rules, that
might make sense.
- Should we automatically add compile and runtime configurations for
each source set? That is, when source set nnn is added, should we
add configuations nnnCompile and nnnRuntime (if they don't exist)?
I guess we could also use rules here (although a classpath is
something you usually always need in conjunction with source set's).
I'm very excited about this. For me this is the big step away from a
layout-driven approach towards a rich build language. It will also
serve as a good example how to solve other domain's with Gradle in the
future.
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
