Hi,
With the new source sets DSL, you can define multiple source sets of various
types and multiple binaries and attach source sets as inputs to binaries. Each
source set can be used as source input to multiple binaries, and each binary
can accept multiple source sets as input.
Each source set added to a binary is compiled separately from the other inputs.
The idea here is this allows you to compose a binary from source sets compiled
in various different ways. To jointly compile all source for a binary, you
first compose the source into a single source set and then attach that to the
binary. So, for each (source-set, binary) edge in the graph, there is a compile
task, and we need a naming scheme for these.
For this discussion 'compile task' just means some kind of transformation task,
like processing resources or compiling some java or generating some byte code
or whatever. Just assume that whatever we come up with for compilation works
can be tweaked to work for processing resources and other things.
Let's assume that each source set and binary has some kind of unique name or
path. Given this, some kind of expressive naming scheme such as the one we use
for publishing is a good option, something like
`compile${SourceSet}For${Binary}Classes`:
source {
main {
java { …. }
java5 { …. }
}
}
binaries {
jvm {
main(ClassDirectoryMain) {
source source.main.java
source source.main.java5
}
}
}
So, you'd end up with `compileMainJavaForMainClasses` and
`compileMainJava5ForMainClasses` as task names. You could argue that these
names are kind of awkward. However, these are worker tasks that usually you
wouldn't run (you'd run `gradle classes` instead) or configure (the compile
settings will mostly be inferred from the configuration of the source set and
the binary) or declare a dependency on (you'd use the binary as input instead).
One issue here is what we do about backwards compatibility. The `java` and
`java-base` plugins add adapters for each old source set and a binary for its
output, so that you can use the new model with the old plugins. The idea is
that we'll migrate everything that consumes the old language model across to
consume this new model instead (this would include the code quality, IDE,
sonar, publishing plugins), so that they continue to work with the old language
plugins but can also deal with new and interesting conventions (e.g. the
Android plugin conventions).
For the compile tasks that are added for these legacy source sets, we need to
use a backwards compatible naming scheme, perhaps something like:
- When compiling the `main.java` legacy source set for the `main` legacy
binary, the task is called `compileJava`.
- When compiling the `${name}.java` legacy source set for the `${name}` legacy
binary, the task is called `compile${Name}Java`
- Otherwise, to compile the `${sourceSet}` source set for the `${binary}`
binary, the task is called `compile${SourceSet}For${Binary}Classes`
This would mean that we'd use a different naming scheme for compiling
`main.java` for the `main` binary if you defined these via the `java` plugin,
vs. some new plugin or directly in the DSL. Eventually, we'd deprecate and
remove the legacy source sets and then everything would use a consistent, if
somewhat verbose, naming scheme.
Another option would be to drop the legacy constraint from the rules above:
- When compiling the `main.${lang}` source set for the `main` binary, the task
is called `compile${Lang}`.
- When compiling the `${function}.${lang}` source set for the `${function}`
binary, the task is called `compile${Function}${Lang}`.
- Otherwise, to compile the `${sourceSet}` source set for the `${binary}`
binary, the task is called `compile${SourceSet}For${Binary}Classes`.
So, for our example above, we'd end up with `compileJava` and `compileJava5`.
What this means is that we somewhat nicer names for the common cases.
Thoughts? Alternatives?
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA:
http://www.gradlesummit.com
