Chapter 24. The Groovy Plugin

To use the Groovy plugin, include the following in your build script:

apply plugin: 'groovy'

The Groovy plugin adds the following tasks to the project.

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

Figure 24.1. Groovy plugin - tasks

The Groovy plugin assumes the project layout shown in Table 24.3, “Groovy plugin - project layout”. All the Groovy source directories can contain Groovy and Java code. The Java source directories may only contain Java source code. ^[11] None of these directories need to exist or have anything in them; the Groovy plugin will simply compile whatever it finds.

sourceSets {
    main {
        groovy {
            srcDirs = ['src/groovy']
        }
    }

    test {
        groovy {
            srcDirs = ['test/groovy']
        }
    }
}

Because Gradle's build language is based on Groovy, and parts of Gradle are implemented in Groovy, Gradle already ships with a Groovy library (2.3.3 as of Gradle 2.0). Nevertheless, Groovy projects need to explicitly declare a Groovy dependency. This dependency will then be used on compile and runtime class paths. It will also be used to get hold of the Groovy compiler and Groovydoc tool, respectively.

If Groovy is used for production code, the Groovy dependency should be added to the compile configuration:

repositories {
    mavenCentral()
}

dependencies {
    compile 'org.codehaus.groovy:groovy-all:2.3.6'
}

If Groovy is only used for test code, the Groovy dependency should be added to the testCompile configuration:

dependencies {
    testCompile "org.codehaus.groovy:groovy:2.3.6"
}

To use the Groovy library that ships with Gradle, declare a localGroovy() dependency. Note that different Gradle versions ship with different Groovy versions; as such, using localGroovy() is less safe then declaring a regular Groovy dependency.

dependencies {
    compile localGroovy()
}

The Groovy library doesn't necessarily have to come from a remote repository. It could also come from a local lib directory, perhaps checked in to source control:

repositories {
    flatDir { dirs 'lib' }
}

dependencies {
    compile module('org.codehaus.groovy:groovy:1.6.0') {
        dependency('asm:asm-all:2.2.3')
        dependency('antlr:antlr:2.7.7')
        dependency('commons-cli:commons-cli:1.2')
        module('org.apache.ant:ant:1.9.3') {
            dependencies('org.apache.ant:ant-junit:1.9.3@jar',
                         'org.apache.ant:ant-launcher:1.9.3')
        }
    }
}

The “module” reference may be new to you. See Chapter 51, Dependency Management for more information about this and other information about dependency management.

The GroovyCompile and Groovydoc tasks consume Groovy code in two ways: on their classpath, and on their groovyClasspath. The former is used to locate classes referenced by the source code, and will typically contain the Groovy library along with other libraries. The latter is used to load and execute the Groovy compiler and Groovydoc tool, respectively, and should only contain the Groovy library and its dependencies.

Unless a task's groovyClasspath is configured explicitly, the Groovy (base) plugin will try to infer it from the task's classpath. This is done as follows:

Note that the “-indy” variation of each jar refers to the version with invokedynamic support.

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

The Groovy 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.6, “Conventions”).

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

The Groovy plugin also modifies some source set properties:

The Groovy plugin adds a GroovyCompile task for each source set in the project. The task type extends the JavaCompile task (see Section 23.11, “CompileJava”). The GroovyCompile task supports most configuration options of the official Groovy compiler.