Coding With Fun
Home Docker Django Node.js Articles Python pip guide FAQ Policy

Gradle Scala plug-in


May 25, 2021 Gradle


Table of contents


Scala plug-in

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.

Usage

To use the Scala plug-in, include the following statement in the build script:

Use the Scala plug-in

build.gradle

apply plugin: 'scala'  

Task

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

Gradle Scala plug-in

The project layout

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.

Change the layout of the project

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']
        }
    }
}  

Rely on management

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"
}  

Automatic configuration of scalaClasspath

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:

  • If scala-library Jar is found in classpath and the item has declared it in at least one repository, the corresponding scala-compiler warehouse dependency is added to scalaClasspath.
  • In other cases, the task will fail to execute and prompt that scalaClasspath cannot be inferred.

Convention properties

The Scala plug-in did not add any convention properties to the project.

Source set property

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.

Fast Scala Compiler

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.

Compiled in an external process

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

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.

eclipse integration

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.

IntelliJ integration

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.