<plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.3</version>
        <executions>
          <execution>
            <id>scala-compile</id>
            <phase>compile</phase>
            <configuration>
              <tasks>
                <property name="build.compiler" value="extJavac"/>
                <taskdef resource="scala/tools/ant/antlib.xml" classpathref="maven.compile.classpath"/>
                <mkdir dir="${project.build.outputDirectory}"/>
                <scalac srcdir="src/main" destdir="${project.build.outputDirectory}" classpathref="maven.compile.classpath">
                  <include name="scala/**/*.scala"/>
                  <include name="scala/**/*.java"/>
                </scalac>
                <javac srcdir="src/main" destdir="${project.build.outputDirectory}" classpathref="maven.compile.classpath">
                  <include name="scala/**/*.java"/>
                </javac>
              </tasks>
            </configuration>
            <goals>
              <goal>run</goal>
            </goals>
          </execution>
          <execution>
            <id>scala-test-compile</id>
            <phase>test-compile</phase>
            <configuration>
              <tasks>
                <property name="build.compiler" value="extJavac"/>
                <taskdef resource="scala/tools/ant/antlib.xml" classpathref="maven.compile.classpath"/>
                <mkdir dir="${project.build.testOutputDirectory}"/>
                <scalac srcdir="src/test" destdir="${project.build.testOutputDirectory}" classpathref="maven.test.classpath">
                  <include name="scala/**/*.scala"/>
                  <include name="scala/**/*.java"/>
                </scalac>
                <javac srcdir="src/test" destdir="${project.build.testOutputDirectory}" classpathref="maven.test.classpath">
                  <include name="scala/**/*.java"/>
                </javac>
              </tasks>
            </configuration>
            <goals>
              <goal>run</goal>
            </goals>
          </execution>
        </executions>
        <dependencies>
          <dependency>
            <groupId>org.scala-lang</groupId>
            <artifactId>scala-compiler</artifactId>
            <version>2.7.5</version>
          </dependency>
        </dependencies>
      </plugin>

Personally, I think that Buildr is really the only way to go for Scala projects. It’s faster than Maven, far easier to configure, and requires less manual tweaking than Ant. It especially shines when it comes time to include a dependency that isn’t in a Maven repo. Its only problem is the fact that it doesn’t have Scala/Java joint compilation in the mainline trunk/ (working on that).

When Groovy does a joint compile it is really a three step process: Generate Groovy Stubs, call JavaC on the .java files with the stubs as non-compiled source, compile Groovy with the JavaC Results in the classpath. The clever part from the IntelliJ guys was the stub generation. A signature equivalent java file is generated from the Groovy source and made available to JavaC Since the transform is fairly simple and does not vary based on the actual libraries used no external code needs to be referenced, it’s just a text transformation on the AST. It looks to me Scala is parsing the Java source and just creating data in it’s compiler tables to handle the symbols and verification for the Scala code.

However, if Scala, Jython, JRuby, JavaFX Script, etc. had stub generation code then a grand unified compiler could be written, but it gets messy at n=3 if Groovy calls JRuby for example, the stubs would need to be compiled and segregated so that they don’t get exposed to the Groovy code. It would be a really neat hack and would help the case for JVM polygot programming a lot. But, alas, not enough spare time.

This is great… the fact that Scala now will allow compiling cross-dependencies with pure Java code and also the fact that you provided everyone with a handy writeup and cheatsheet.

What bothers me is that in my mind this solves the wrong problem. The REAL objective is not allowing compilation of projects containing both Scala and Java code, but compilation of projects containing mixed code of various languages that interoperate on the JVM. Jython, Groovy, Scala, and Java should all be able to co-exist. They can effectively all use Java as an inter-language interface, and they can all compile today so long as there are no circular dependencies. But introduce circular dependencies and you are now restricted to Groovy-and-Java, or Scala-and-Java, or basically any combination of languages so long as the “youngest” compiler is aware of all the languages.

Or you can try playing tricks with multiple compilation passes — compile certain sources in one language, then other sources in another, then back to the first language. I can say from experience that this approach gets unmanageable VERY rapidly.

What IS the ideal solution? Perhaps a standard facility that compilers like Groovy, Scala, Jythonc, and others can implement which would allow them to be invoked just to produce the AST (perhaps in the form of a stub .class file). Does anyone reading this know of any attempts to produce such a thing?