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. 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 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 Please have a look at the code and tell me if more changes are needed before it can be used. Ross 2009/8/3 Hans Dockter <[email protected]> > Hi Ross, > > On Aug 3, 2009, at 11:24 AM, Ross Black wrote: > > Hi, >> >> I am reviving the patch in a git branch: >> http://github.com/black/gradle-scala/ >> > > Cool. > > >> I will initially just get the existing code working again, and then we can >> figure out what other changes, and simplifications (as Jeppe suggested) to >> apply. >> > > Good plan. > > >> Just a couple of questions: >> >> - if this is to be included in the main gradle code (I assume that is >> where it will live until the plugin repository mechanism is figured out?), >> > > Yes. Although let's see how soon we get some plugin mechanism running. > > are you still attempting to have all that code written in Java? >> > > We have discussed this recently and are not sure if this is really a good > strategy. > > - I assume use of ant is OK in the short term? >> > > Yes. > > I do plan to eventually convert away from use of ant and instead directly >> call the Scala compiler api >> > > One thing that we try to achieve is to make our tasks rich and optimizable. > Rich means for example to provide information about the execution process > (e.g. number of classes compiled). Optimizable means that a task should be > able to tell whether it really did some work. If the task didn't than other > tasks might have not do any work as well. This is harder to achieve when > delegating to the Ant tasks. Although Steve Appling managed to do it for the > Javac task (you might have a look there). > > > - Hans > > -- > Hans Dockter > Gradle Project Manager > http://www.gradle.org > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
