Table of Contents
The Scala plugin extends the Java plugin to add support for Scala projects. It can deal with Scala code, mixed Scala and Java code, and even pure Java code (although we don't necessarily recommend to use it for the latter). The plugin supports joint compilation, which allows you to freely mix and match Scala and Java code, with dependencies in both directions. For example, a Scala class can extend a Java class that in turn extends a Scala class. This makes it possible to use the best language for the job, and to rewrite any class in the other language if needed.
To use the Scala plugin, include the following in your build script:
The Scala plugin adds the following tasks to the project.
Table 54.1. Scala plugin - tasks
Task name | Depends on | Type | Description |
compileScala |
compileJava |
ScalaCompile |
Compiles production Scala source files. |
compileTestScala |
compileTestJava |
ScalaCompile |
Compiles test Scala source files. |
compile |
compile |
ScalaCompile |
Compiles the given source set's Scala source files. |
scaladoc |
- | ScalaDoc |
Generates API documentation for the production Scala source files. |
The Scala plugin adds the following dependencies to tasks added by the Java plugin.
Table 54.2. Scala plugin - additional task dependencies
Task name | Depends on |
classes
|
compileScala
|
testClasses
|
compileTestScala
|
|
compile
|
The Scala plugin assumes the project layout shown below. All the Scala source directories can contain Scala and Java code. The Java source directories may only contain Java source code. None of these directories need to exist or have anything in them; the Scala plugin will simply compile whatever it finds.
Table 54.3. Scala plugin - project layout
Directory | Meaning | |
src/main/java
|
Production Java source | |
src/main/resources
|
Production resources | |
src/main/scala
|
Production Scala sources. May also contain Java sources for joint compilation. | |
src/test/java
|
Test Java source | |
src/test/resources
|
Test resources | |
src/test/scala
|
Test Scala sources. May also contain Java sources for joint compilation. | |
src/
|
Java source for the given source set | |
src/
|
Resources for the given source set | |
src/
|
Scala sources for the given source set. May also contain Java sources for joint compilation. |
Scala projects need to declare a scala-library
dependency. This dependency will then be used on compile and
runtime class paths. It will also be used to get hold of the Scala compiler and Scaladoc tool, respectively.
[28]
If Scala is used for production code, the scala-library
dependency should be added to the
compile
configuration:
Example 54.3. Declaring a Scala dependency for production code
build.gradle
repositories {
mavenCentral()
}
dependencies {
compile 'org.scala-lang:scala-library:2.11.1'
}
If Scala is only used for test code, the scala-library
dependency should be added to the testCompile
configuration:
Example 54.4. Declaring a Scala dependency for test code
build.gradle
dependencies {
testCompile "org.scala-lang:scala-library:2.11.1"
}
The ScalaCompile
and ScalaDoc
tasks consume Scala code in two ways: on their classpath
,
and on their scalaClasspath
. The former is used to locate classes referenced by the source code, and will typically
contain scala-library
along with other libraries. The latter is used to load and execute the Scala compiler
and Scaladoc tool, respectively, and should only contain the scala-compiler
library and its dependencies.
Unless a task's scalaClasspath
is configured explicitly, the Scala (base) plugin will try to infer it
from the task's classpath
. This is done as follows:
scala-library
Jar is found on classpath
, and the project has at least one repository declared,
a corresponding scala-compiler
repository dependency will be added to scalaClasspath
.
scalaClasspath
could not be inferred.
The Scala plugin adds the following convention properties to each source set in the project. You can use these properties in your build script as though they were properties of the source set object.
Table 54.4. Scala plugin - source set properties
Property name | Type | Default value | Description |
scala
|
SourceDirectorySet (read-only)
|
Not null |
The Scala source files of this source set. Contains all .scala and
.java files found in the Scala source directories, and excludes all other
types of files.
|
scala.srcDirs
|
Set<File> . Can set using anything described in Section 18.5, “Specifying a set of input files”.
|
[
|
The source directories containing the Scala source files of this source set. May also contain Java source files for joint compilation. |
allScala
|
FileTree (read-only)
|
Not null |
All Scala source files of this source set. Contains only the .scala files
found in the Scala source directories.
|
These convention properties are provided by a convention object of type ScalaSourceSet
.
The Scala plugin also modifies some source set properties:
Table 54.5. Scala plugin - source set properties
Property name | Change |
allJava
|
Adds all .java files found in the Scala source directories. |
allSource
|
Adds all source files found in the Scala source directories. |
Scala compilation takes place in an external process.
Memory settings for the external process default to the defaults of the JVM. To adjust memory settings,
configure the scalaCompileOptions.forkOptions
property as needed:
Example 54.5. Adjusting memory settings
build.gradle
tasks.withType(ScalaCompile) { configure(scalaCompileOptions.forkOptions) { memoryMaximumSize = '1g' jvmArgs = ['-XX:MaxPermSize=512m'] } }
By compiling only classes whose source code has changed since the previous compilation, and classes affected by these changes, incremental compilation can significantly reduce Scala compilation time. It is particularly effective when frequently compiling small code increments, as is often done at development time.
The Scala plugin defaults to incremental compilation by integrating with Zinc,
a standalone version of sbt's incremental Scala compiler. If you want to disable the
incremental compilation, set force = true
in your build file:
Example 54.6. Forcing all code to be compiled
build.gradle
tasks.withType(ScalaCompile) { scalaCompileOptions.with { force = true } }
Note: This will only cause all classes to be recompiled if at least one input source file has changed. If there are
no changes to the source files, the compileScala
task will still be considered UP-TO-DATE
as usual.
The Scala plugin adds a configuration named zinc
to resolve the Zinc library and its dependencies.
Gradle will have a default version of the Zinc library, but if you want to override the
Zinc version that Gradle uses, add an explicit dependency like “com.typesafe.zinc:zinc:0.3.6”
. Gradle will support
version 0.3.0 of Zinc and above, although due to a regression in the Zinc library, versions 0.3.2 through 0.3.5.2 cannot be used.
Regardless of which Zinc version is used, Zinc will always use the Scala compiler found on the scalaTools
configuration.
The Zinc-based Scala Compiler supports joint compilation of Java and Scala code. By default, all Java and Scala code
under src/main/scala
will participate in joint compilation. Even Java code will be compiled incrementally.
Incremental compilation requires dependency analysis of the source code. The results of this analysis are stored in the file designated
by scalaCompileOptions.incrementalOptions.analysisFile
(which has a sensible default). In a multi-project build, analysis
files are passed on to downstream ScalaCompile
tasks to enable incremental compilation across project boundaries. For
ScalaCompile
tasks added by the Scala plugin, no configuration is necessary to make this work. For other
ScalaCompile
tasks that you might add, the property scalaCompileOptions.incrementalOptions.publishedCode
needs to be configured to point
to the classes folder or Jar archive by which the code is passed on to compile class paths of downstream ScalaCompile
tasks.
Note that if publishedCode
is not set correctly, downstream tasks may not recompile code affected by upstream changes,
leading to incorrect compilation results.
Note that Zinc's Nailgun based daemon mode is not supported. Instead, we plan to enhance Gradle's own compiler daemon to stay alive across Gradle invocations, reusing the same Scala compiler. This is expected to yield another significant speedup for Scala compilation.
When the Eclipse plugin encounters a Scala project, it adds additional configuration to make the project work with Scala IDE out of the box. Specifically, the plugin adds a Scala nature and dependency container.
When the IDEA plugin encounters a Scala project, it adds additional configuration to make the project work with IDEA out of the box. Specifically,
the plugin adds a Scala SDK (IntelliJ IDEA 14+) and a Scala compiler library that matches the Scala version on the project's class path.
The Scala plugin is backwards compatible with earlier versions of IntelliJ IDEA and it is possible to add a Scala facet instead of the default Scala SDK
by configuring targetVersion
on IdeaModel
.
Example 54.7. Explicitly specify a target IntelliJ IDEA version
build.gradle
idea {
targetVersion = "13"
}