Steve Appling wrote:
Adam Murdoch wrote:
Hi,
I've been making some changes to allow any combination of Java,
Groovy and Scala source to be used for a project. The guts of this
change is that the 'compile' task of each source set has been split
into:
- compileJava: of type Compile, compiles every thing in src/main/java
using javac
- compileGroovy: of type GroovyCompile, compiles everything in
src/main/groovy using groovyc+javac. Handles joint groovy and java
compilation
- compileScala: of type ScalaCompile, compiles everything in
src/main/scala using scalac+javac. Handles joint scala and java
compilation
- compile: dependsOn compileJava, compileGroovy, compileScala,
processResources
compileGroovy and compileScala are added by the Groovy and Scala
plugins, respectively. The rest are added by the Java plugin.
We don't handle joint Groovy, Scala and Java compilation.
I've also made some changes to the lifecycle tasks:
- libs and dists have been merged into assemble
- moved the check task from the code quality plugin to the java plugin
- changed check to depend on test
Adam
I don't have a better answer, but I still feel it is awkward to have
the language in the task name. Even if I could always use the compile
task from the command line (because of the dependency), I have to use
the task with the language name when setting up the options. I guess
it's just habit, but I keep using compile.options.
I suspect it's habit. How could you possibly not know the target
language when you want to configure the compiler for that language?
One benefit of having the target language in the task name is that it
makes it explicit which compiler is being configured. Previously, the
name 'compile' might have referred to a Compile, GroovyCompile or
ScalaCompile task, and
compile.options.something
is not clear what I'm configuring here. I need to go and look for the
appropriate usePlugin() call, which might be in another build script,
such as the root project.
compileJava.options.something
compileScala.options.something
is better at self-describing. Plus I get a failure at evaluation time if
I've made a mistake.
Another benefit is that you now have the possibility to configure javac
differently for compiling stand-alone Java, and for joint compilation.
There's a few negatives to the current approach:
* It's noisy. You get compileJava/compileTestJava regardless of whether
you have any stand-alone Java in the project. I guess most Groovy or
Scala projects don't have stand-alone Java
We could address this by fixing up gradle -t to do something smarter by
default.
Another option would be to chop up the Java/Groovy/Scala plugins into a
few pieces:
1. The lifecycle: Adds tasks like clean, assemble, check, build,
buildNeeded, etc.
2. The basic source set stuff: Adds the ability to define source sets,
but they don't do anything. Wires them into the lifecycle.
3. The standard source sets: Adds the 'main' and 'test' source sets,
plus their configurations and sets up their classpaths.
4. The Java compile tasks: Each source set gets a compileJava task and a
'java' source property.
5. The Groovy compile tasks: Each source set gets a compileGroovy task
and a 'groovy' source property.
6. The Scala compile tasks: Each source set gets a compileScala task and
a 'scala' source property.
Then:
usePlugin 'java' would apply 1,2, 3, 4
usePlugin 'groovy' would apply 1,2,3,5
usePlugin 'scala' would apply 1,2,3,6
* If you want to configure javac for both stand-alone Java and joint
Java Groovy compilation, you have to configure both compileJava and
compileGroovy
We can address this by adding the options to the source set object:
source {
main {
javac.someJavacOption = '-Xsomething
groovyc.someGroovycOption = 'some groovy thing'
scalac.someScalacOption = 12
}
}
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
