2009/8/12 Adam Murdoch <[email protected]> > > > 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.
done > > > - An integration test would be good, to exercise the scala quickstart > sample. You could simply copy SamplesJavaQuickstartIntegrationTest. done > > > - You could get rid of the customValues from the ScalaPluginConvention > constructor, as we got rid of these from all the other conventions. done. > > > >> >> 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 Yep, it should definitely be using the compile configuration. I will add a test that breaks, and then fix the configuration. > > - 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? I avoided doing any java compilation / javadoc in this first version so the plugin will only work with a pure scala project. I was hoping to deal with that next when looking at mixed compilation. The more recent versions of scala allow mixed compilation where java and scala can depend on each other. As I understand it the sequence should be: 1. Run the scala compiler to both parse java code and generate bytecode classes from scala code (it does not generate bytecode for the java) 2. Run the java compiler (giving it the classes generated from the scala compiler) 3. Optionally run the scala compiler again but compilng the scala code from the java bytecode classes (apparently to catch some problems with the java parsing performed by scala) It should probably allow configuration of these phases for projects that do not have the cyclic dependencies. > > - Why is the scalaTools configuration non-transitive? Just a copy and paste following the pattern from the groovy plugin. I assume both scala and scalaTools be 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. Separating the tasks for each compiler type would make sense to me. That could allow the prime 'compile' task to setup dependencies based on specific project needs. eg one project may have groovy code depending on java code, another may have java code depending on groovy code. Dealing with cycles (as for scala) becomes a little trickier. > > - 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? To me it would make sense to merge the options into the tasks. My initial impression from writing the scala plugin was that there is a awful lot of classes needed for something that should be relatively simple (but I am yet to understand how it all works). > > > 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 :) > > I will add all of these to the current jira issue. Thanks, Ross > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
