Hans Dockter wrote:
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:
- 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.
This doesn't seem worth the noise it adds. Why should we hide the fact
that the 'main' source set is being compiled?
Which make me think of we shouldn't explicitly support aliases for
task names (vs. creating a new task that depends on another task)?
I don't really see the point. We could choose better names for our
tasks, instead, I think.
- 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.
You could say the same things about pretty much everything that the java
plugin adds to the project. What we really need is some way to figure
out which tasks are required for a source set. Perhaps we could attach
roles or something to a source set which indicate how it will be used:
- A test suite: we would compile, processResources, and test (and
checkstyle, codenarc)
- A library: we would compile, processResources, javadoc, jar (and
checkstyle, codenarc, coverage)
- Packaged in an application: we could compile, processResources,
javadoc (and war, checkstyle, codenarc, coverage)
You could apply zero or more roles to a source set, and perhaps plugins
could contribute new roles.
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.
It might not be, particularly if we do something to distinguish between
lifecycle and worker tasks, as John has suggested.
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).
That might be a good idea.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
