Ross Black wrote:
2009/8/12 Adam Murdoch <[email protected]
<mailto:[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.
Thanks. Is this ready to merge now, do you think?
- 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.
That's fine.
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?
I wonder. The 'compile' configuration is non-transitive, so 'scala'
should probably be too.
- 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).
I agree. Any ideas on what we could simplify? (you can't say 'not
writing tests', either :)
Adam
