Ross Black wrote:
Hi,
I have completed updating the scala plugin to work with the latest
gradle code.
The code is in http://github.com/black/gradle-scala/ and should now be
ready to integrate into the main code repository (if it looks ok).
It looks good. There's a couple of minor things that would be nice to
fix up before merging this in:
- Some of the files have a corporate copyright notice in the header.
These would need to be changed to the standard Gradle notice.
- An integration test would be good, to exercise the scala quickstart
sample. You could simply copy SamplesJavaQuickstartIntegrationTest.
- You could get rid of the customValues from the ScalaPluginConvention
constructor, as we got rid of these from all the other conventions.
It has tasks to compile scala code and tests, and to generate scala
documentation from the source code.
The tasks are implemented using ant. I have separated the ant code
into AntScalaDefine, AntScalaCompile, and AntScalaDoc to make it
easier to replace (or supplement) these implementations with code that
uses the scala compiler API directly.
A sample is provided, and all of the code has unit tests (except for
the Ant* code - I still want to figure out a reasonable way to test
this code).
Some notes / issues:
- 2 configurations are used (scala, and scalaTools) so that the scala
tools jar does not pollute the classpath used for compilation of
application code. The ScalaDefine task is used to add the scala ant
tasks into the project ant. (there are some other ant tasks that this
makes available that are not exposed via the gradle tasks).
- Should bootclasspath and extpath be part of compile/doc options? I
put them as part of the constructor of the Ant* classes. This was an
attempt to get a common signature for all compile ant tasks so that
the compiler can be switched easily.
- How many options should get put on the convention object? Every
option is available on the ScalaCompile, but is not exposed in the
convention
I have some questions/comments:
- It looks like compile task is using the 'scala' configuration rather
than the 'compile' configuration for the compilation classpath.
Shouldn't it be using the 'compile' configuration? (compileTests task
uses the 'testCompile' configuration)
- Same question as above, for the scaladoc task
- The scala compile task doesn't seem to do any java compilation at all.
Should it work like the groovy compile task, so that everything in
src/main/java is compiled using javac, and then everything in
src/main/scala is compiled using scalac?
- Why is the scalaTools configuration non-transitive?
- How are we going to deal with mixed java+groovy+scala projects?
Currently the groovy and scala plugins both overwrite the
compile/compileTests tasks. Obviously this is not going to work when
they are used together. Perhaps, instead, they should add extra tasks
and leave the compile tasks alone. For example, the groovy plugin could
add compileGroovy and compileGroovyTests which compile everything under
src/main/groovy using groovyc, and the scala plugin adds compileScala
and compileScalaTests which compile everything under src/main/scala
using scalac.
- The approach of using a separate define task is different to how the
other plugins define the custom ant tasks they need. It would be nice to
have a consistent approach to this problem. I don't know what that
should be.
- I'm not sure why we have separate options objects for many of our
tasks. For example, I don't really see the need for a separate
ScalaCompileOptions or ScalaDocOptions class. I know this is just
copying the pattern we use all through the other plugins. I wonder if
this is really a good idea, or whether we should simplify this by
inlining the options objects into the task objects?
Some future development:
- Implement feedback to indicate that work has been done (ie. files
compiled)
- Allow mixed compilation of scala and java (the scala compiler now
allows mutual dependencies between scala and java)
- Possibly integrate some of the functionality from sbt
(http://code.google.com/p/simple-build-tool/) to provide incremental
compilation
+1 to all of these.
I would add:
- add a chapter to the userguide :)
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
