Файл: Gradle.pdf

[9] We don't recommend this, as the Groovy plugin uses theGroovyc Ant task to compile the sources. For pure Java projects you might rather stick with javac. In particular as you would have to supply a groovy jar for doing this.

[10] We are using the same conventions as introduced by Russel Winders Gant tool ( http://gant.codehaus.org).

Page 161 of 343

25

The Scala Plugin

The Scala plugin extends the Java plugin to add support for Scala projects. It can deal with Scala-only projects and with mixed Java/Scala projects. It can even deal with Java-only projects. The Scala plugin supports joint compilation of Java and Scala source. This means your project can contain Scala classes which use Java classes, and vice versa.

25.1. Usage

To use the Scala plugin, include in your build script:

Example 25.1. Using the Scala plugin

build.gradle

apply plugin: 'scala'

25.2. Tasks

The Scala plugin adds the following tasks to the project.

Page 162 of 343

The Scala plugin adds the following dependencies to tasks added by the Java plugin.

Table 25.2. Scala plugin - additional task dependencies

classes compileScala

testClasses compileTestScala

sourceSetClasses compileSourceSetScala

Figure 25.1. Scala plugin - tasks

25.3. Project layout

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 exist or have anything in them. The Scala plugin will compile whatever it finds, and handles anything which is missing.

Page 163 of 343

Table 25.3. Scala plugin - project layout

src/sourceSet/java Java source for the given source set src/sourceSet/resourcesResources for the given source set

src/sourceSet/scala Scala source for the given source set. May also contain Java source for joint compilation.

25.3.1. Changing the project layout

TBD

Example 25.2. Custom Scala source layout

build.gradle

sourceSets { main {

scala {

srcDir 'src/scala'

}

}

}

25.4. Dependency Management

The Scala plugin adds a scalaTools configuration, which it uses to locate the Scala tools, such as scalac, to use. You must specify the version of Scala to use. Below is an example.

Page 164 of 343

Example 25.3. Declaring the Scala version to use

build.gradle

repositories { mavenCentral()

}

dependencies {

//Libraries needed to run the scala tools scalaTools 'org.scala-lang:scala-compiler:2.8.1' scalaTools 'org.scala-lang:scala-library:2.8.1'

//Libraries needed for scala api

compile 'org.scala-lang:scala-library:2.8.1'

}

25.5. Convention Properties

The Scala plugin does not add any convention properties to the project.

25.6. Source set properties

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 (see Section 21.3, “Conventions”).

Table 25.4. Scala plugin - source set properties

Page 165 of 343

These convention properties are provided by a convention object of type ScalaSourceSet.

The Scala plugin also modifies some source set properties:

Table 25.5. Scala plugin - source set properties

25.7. Fast Scala Compiler

The Scala plugin includes support for fsc, the Fast Scala Compiler. fsc runs in a separate daemon process and can speed up compilation significantly.

Example 25.4. Enabling the Fast Scala Compiler

build.gradle

compileScala { scalaCompileOptions.useCompileDaemon = true

// optionally specify host and port of the daemon: scalaCompileOptions.daemonServer = "localhost:4243"

}

Note that fsc expects to be restarted whenever the contents of its compile class path change. (It does detect changes to the compile class path itself.) This makes it less suitable for multi-project builds.

Page 166 of 343

26

The War Plugin

The War plugin extends the Java plugin to add support for assembling web application WAR files. It disables the default JAR archive generation of the Java plugin and adds a default WAR archive task.

26.1. Usage

To use the War plugin, include in your build script:

Example 26.1. Using the War plugin

build.gradle

apply plugin: 'war'

26.2. Tasks

The War plugin adds the following tasks to the project.

Table 26.1. War plugin - tasks

The War plugin adds the following dependencies to tasks added by the Java plugin.

Table 26.2. War plugin - additional task dependencies

Page 167 of 343

Figure 26.1. War plugin - tasks

26.3. Project layout

Table 26.3. War plugin - project layout

src/main/webapp Web application sources

26.4. Dependency management

The War plugin adds two dependency configurations: providedCompile and providedRuntime

. Those configurations have the same scope as the respective compile and runtime configurations, except that they are not added to the WAR archive. It is important to note that those provided configurations work transitively. Let's say you addcommons-httpclient:commons-h to any of the provided configurations. This dependency has a dependency on commons-codec. This means neither httpclient nor commons-codec is added to your WAR, even if commons-c were an explicit dependency of your compile configuration. If you don't want this transitiv behavior, simply declare your provided dependencies like commons-httpclient:commons-ht

.

26.5. Convention properties

Table 26.4. War plugin - directory properties

These properties are provided by a WarPluginConvention convention object.

26.6. War

The default behavior of the War task is to copy the content of src/main/webapp to the root of the archive. Your webapp directory may of course contain a WEB-INF sub-directory, which again may contain a web.xml file. Your compiled classes are compiled to WEB-INF/classes. All the dependencies of the runtime configuration are copied to WEB-INF/lib.

Page 168 of 343