Hi, Sorry for the late reply, been busy after returning from vacation :-)
I've tried the plugin for our (scala-only) app and it seems to work fine. Good job! I've only used the compile & test tasks, not scaladoc Only initial hurdle was that the scala plugin is missing from plugin.properties A few more comments below.... On Tue, Aug 11, 2009 at 3:31 PM, Ross Black<[email protected]> 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 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. I'm wondering why defineScalaAnt is needed as a task? It seems unnecessary and a little confusing. The other plugins simply define that ant tasks when needed. > 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). I'm still a little unclear why we need both scala & scalaTools? I agree the scala tools jar should not be included in the war/jar but why the "scala" config? > - 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 > > 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) You might look into how it is done in buildr (I haven't tried it so don't know how well it works, but it looks fairly simple). http://github.com/buildr/buildr/blob/32766dc792461b51bf40e09fb9f07bf44a50f943/lib/buildr/scala/compiler.rb /Jeppe --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
