May 25, 2021 Gradle
Scala's plug-in inherits from the Java plug-in and adds support for scala projects. I t can handle Scala code, as well as hybrid Scala and Java code, and even pure Java code (although we don't necessarily recommend it). T he plug-in supports co-compilation, which can be arbitrarily mixed and matched by Scala and Java's respective dependencies. F or example, a Scala class can inherit from a Java class, and this Java class can inherit from a Scala class. This allows us to use the most appropriate language in the project and rewrite any of its classes in other languages if necessary.
To use the Scala plug-in, include the following statement in the build script:
Use the Scala plug-in
build.gradle
apply plugin: 'scala'
Scala's plug-in adds the following tasks to the project.
Table 25.1. Scala plug-in - task
The name of the task | Depends on | Type | Describe |
compileScala
|
compileJava
|
ScalaCompile | Compile the Scala source file for the action. |
compileTestScala
|
compileTestJava
|
ScalaCompile | Compile the source file for The Scala of test. |
SourceSet
Scala
|
SourceSet
Java
|
ScalaCompile | Compile the Scala source file in a given source set. |
scaladoc
|
- | scaladoc | Build an API document for the Scala source file in the action. |
The Scala plug-in adds the following dependencies to the tasks that the Java plug-in joins.
Table 24.2. Scala Feel Plug-in - Extra Task Dependency
The name of the task | Depends on |
classes
|
compileScala
|
testClasses
|
compileTestScala
|
sourceSet
Classes
|
SourceSet
Scala
|
Figure 25.1. Scala plug-in - task
The Scala plug-in assumes the project layout as shown below. A ll Scala's source directories can contain Scala and Java code. T he Java source directory can only contain Java source code. These directories do not necessarily exist, or contain anything; the Scala plug-in only compiles, no matter what it finds.
Table 25.3. Scala plug-in - project layout
Directory | Significance |
src/main/java
|
Java source code for the product |
src/main/resources
|
The resources of the product |
src/main/scala
|
Production Scala source code. It may also contain co-compiled Java source code. |
src/test/java
|
Java tests the source code |
src/test/resources
|
Test the resource |
src/test/scala
|
Test Scala source code. It may also contain co-compiled Java source code. |
sourceSet
/java
|
Java source code for a given source set |
sourceSet
/resources
|
The resource for the given source set |
sourceSet
/scala
|
The Scala source code for the given source set. It may also contain co-compiled Java source code. |
Like the Java plug-in, the Scala plug-in allows the source files of Scala's production and test to be configured as custom locations.
Customize the Scala source file layout
build.gradle
sourceSets {
main {
scala
srcDirs = ['src/scala']
}
}
test {
scala
srcDirs = ['test/scala']
}
}
}
The Scala project needs to declare a scala-library dependency. T his dependency is used when compiling and running class paths. It will also be used to get the Scala compiler and the Scaladoc tool, respectively.
If Scala is used for production code, scala-library dependencies should be added to the configuration of compile:
Define a Scala dependency for the action code
build.gradle
repositories {
mavenCentral()
}
dependencies {
compile 'org.scala-lang:scala-library:2.9.1'
}
If Scala is used only to test code, scala-library dependencies should be added to the testCompile configuration:
Define a Scala dependency for the test code
build.gradle
dependencies {
testCompile "org.scala-lang:scala-library:2.9.2"
}
ScalaCompile and ScalaDoc tasks use Scala in two ways: on their classpath and scalaClasspath. T he former is used to find references to classes in the source code and typically contains scala-library and other libraries. The latter is used to load and execute scala compilers and Scala tools, respectively, and should contain only scala-library and its dependencies.
Unless a task's scalaClasspath is explicitly configured, the Scala plug-in attempts to infer the task's classpath. in the following manner:
The Scala plug-in did not add any convention properties to the project.
Scala's plug-in adds the following convention properties to each source set of the project. You can use these properties as if they were properties in the source set object in your build script.
Table 25.4. Scala plug-in - source set property
The name of the property | Type | The default | Describe |
scala
|
SourceDirectorySet (read-only) | Not empty |
Scala source file in the source set.
All files contained in the Scala source
.java
and exclude all other types of files.
|
scala.srcDirs
|
Set<File>
.
|
name
/scala]
|
The source directory contains the Scala source file in the source set. It may also contain Java source files for co-compilation. |
allScala
|
FileTree (read-only) | Not empty |
All Scala source files in the source set.
Contains all the
.scala
files found in the Scala source directory.
|
These properties are provided by a contract object of ScalaSourceSet.
Scala's plug-in also modifies some of the properties of source set:
Table 25.5. Scala Plugin - Source Set Attribute
The name of the property | The content of the modification |
allJava
|
Add all the files found in the Scala
.java
directory.
|
allSource
|
Add all source files found in Scala's source directory. |
The Scala plug-in includes support for fsc, or Fast Scala Compiler. fsc runs in a separate process and can significantly improve compilation speed.
Enable Fast Scala Compiler
build.gradle
compileScala
scalaCompileOptions.useCompileDaemon = true
// optionally specify host and port of the daemon:
scalaCompileOptions.daemonServer = "localhost:4243"
}
Note that whenever the contents of fsc's compiled class path change, it needs to be restarted. ( It itself does not detect changes to the compiled class path.) This makes it less suitable for multi-project construction.
When scalaCompileOptions.fork is set to true, compilation occurs in an external process. T he details of fork depend on the compiler used. T he Ant-based compiler (scalaCompileOptions.useAnt-true) will give each ScalaCompile task a new process fork, which is not fork by default. Zinc-based compilers (scalaCompileOptions.useAnt=false) will take advantage of the Gradle compiler daemon, and by default the same is true.
External procedures use JVM's default memory settings by default. If you want to adjust your memory settings, configure scalaCompileOptions.forkOptions as needed:
Adjust the memory settings
build.gradle
tasks.withType(ScalaCompile) {
configure(scalaCompileOptions.forkOptions) {
memoryMaximumSize = '1g'
jvmArgs = ['-XX:MaxPermSize=512m']
}
}
Incremental compilation is the compilation of only those classes where the source code has been modified since the last compilation, and those affected by those modifications, which can greatly reduce Scala's compilation time. It is useful to compile incremental parts of your code frequently, as we often do when developing.
The Scala plug-in now supports incremental compilation by integrating Zinc, a stand-alone version of the sbt incremental Scala compiler. To switch the ScalaCompile task from the default Ant-based compiler to the new Zinc-based compiler, you need to set scalaCompileOptions.useAnt to false:
Activate the Zinc-based compiler
build.gradlev
tasks.withType(ScalaCompile) {
scalaCompileOptions.useAnt = false
}
Unless otherwise noted in the API documentation, Zinc-based compilations support exactly the same configuration options as Ant-based compilers. N ote, however, that the Zinc compiler requires Java 6 or above to run. This means that Gradle itself uses Java 6 or above.
The Scala plug-in adds a configuration called zinc to resolve the Zinc library and its dependencies. I f you want to override the zinc version that Gradle uses by default, add an explicit Zinc dependency (for example, zinc "com.typesafe.zinc:zinc:0.1.4"). Whichever version of Zinc is used, Zinc uses the Scala compiler found on the scalaTools configuration.
Like Ant-based compilers on Gradle, Zinc-based compilers support the co-compilation of Java and Scala code. B y default, all Java and Scala code under src/main/scala is compiled jointly. When you use a Zinc-based compiler, even Java code is incrementally compiled.
Incremental compilation requires a correlation analysis of the source code. T he parsing result goes to the file specified by scalaCompileOptions.incrementalOptions.analysis File (which has a reasonable default value). I n a multi-project build, the analysis file is passed to the ScalaCompile task downstream to enable incremental compilation across projects. T his is not required for ScalaCompile tasks added by the Scala plug-in. F or other ScalaCompile tasks, you need to configure ScalaCompileOptions.incrementalOptions.publishedCode to point to them, depending on which code is passed to the downstream class path of the ScalaCompile task, either in the class folder or in Jar archive's code. Note that if the publisedCode settings are incorrect, downstream tasks may not recompile the code when upstream code changes, resulting in incorrect compilation results.
Due to the overhead of relying on analysis, a clean compilation or compilation after a large change in code can take longer than using an Ant-based compiler. For CI builds and version builds, we currently recommend using an Ant-based compiler.
Note That Zinc's nailgun based on daemon mode is not currently supported. I nstead, we intend to strengthen Gradle's own compiler daemon so that we can continue to live when called across Gradle, using the same Scala compiler. This will lead to a significant acceleration in another aspect of Scala compilation.
When the Eclipse plug-in encounters a Scala project, it adds an additional configuration that enables the project to be out of the box when using Scala IDE. Specifically, the plug-in adds a Scala-specific and dependent container.
When the IDEA plug-in encounters a Scala project, it adds an additional configuration that enables the project to be out of the box when US IDEA is used. Specifically, the plug-in adds a Scala facet and a Scala version of the Scala compiler class library on the class path that matches the project.