Gradle Release Notes

Version 1.9

This release of Gradle primarily provides relief through important bug fixes. It also boosts Gradle's performance through optimizations to incremental building when using the Gradle Daemon and when building in parallel.

The support for building native applications gained an important new feature in this release: “variants”. Variants can be used to model different ways to construct and build a binary (e.g. including debug symbols or not, x86 vs x64). In a given build invocation, all variants may be built in one invocation or just a subset.

The new HTML dependency report added in this release is a compelling alternative to the existing console based report as it leverages the richer medium of HTML to offer more information and navigability. It is extremely useful for analyzing and understanding large dependency graphs.

Two new project types for use with the init command (formerly named buildSetup) have been added, groovy-library and scala-library for creating Groovy and Scala libraries respectively.

Several of the new features and improvements have been contributed by the community. Thank you to all who contributed and please keep the pull requests coming.

Table Of Contents

New and noteworthy

Here are the new features introduced in this Gradle release.

Faster incremental builds when using the Gradle Daemon

Gradle's incremental build support enables a fast feedback cycle by only performing build tasks that are affected by changes that have occurred since the last build. The Gradle Daemon also improves performance by reusing a long lived process, instead of incurring the process initialization cost for each build invocation. In Gradle 1.9, these two features combine to make incremental building even faster when using the Gradle Daemon.

Incremental building support requires internal activities and record keeping (all completely transparent to Gradle users) to track changes to files and configuration. The data required to do this is now cached within the Gradle Daemon, reducing the overhead of the record keeping and making subsequent incremental builds faster.

This is but one example of the kind of optimization that the Gradle Daemon can offer, by way of it being a long lived process. Expect to see further optimizations in future versions of Gradle of this nature.

Faster parallel builds when using forked Java compilation

Gradle has long supported using an external Java process to compile Java code (see the JavaCompile task for configuration details). In previous versions of Gradle, forked Java compilation was a performance bottleneck when building in parallel. As of Gradle 1.9, extra compilation processes will be created as needed when building in parallel.

Forked compilation is generally safer and allows fine grained control of the JVM options of the compilation process as well as decoupling the target JDK from the build JVM. It will become the default way that Java code is compiled in a future version of Gradle.

HTML dependency report

Thanks to a contribution by Jean-Baptiste Nizet, the project-report plugin can now generate an HTML dependency report.

To use the report just apply the plugin:

apply plugin: "project-report"

And run gradle htmlDependencyReport or gradle projectReport

Initializing Groovy or a Scala project

The build-init plugin now ships with two additional templates for initializing a new project:

To initialize a new project just run

gradle init --type groovy-library

on the commandline.

FindBugs plugin provides new reporting capabilities

If the a FindBugs task is configured to produce an XML report, the output can be augmented with human-readable messages.

The follow example demonstrates its use:

findbugsMain.reports {
    xml {
        enabled true
        withMessages true
    }
}

Additionally, reports in text and Emacs formats can now be produced.

findbugsMain.reports {
    text.enabled true
    emacs.enabled true
}

Build multiple variants of a native binary incubating feature

Gradle is rapidly becoming a capable build system for 'native' code projects.

A key goal of the native binary support in Gradle is to make it easy to create multiple different variants of a native binary from the same (or similar) set of sources. In Gradle 1.8 is was trivial to generate a shared and static version of the same library, but in Gradle 1.9 this concept has been taken a lot further. It is now simple to create 'debug' and 'release' variants, binaries targeting different cpu architectures, or variants built using different tool chains.

Here's an example creating 'debug' and 'release' variants targeting 'i386' and 'x86_64' cpu architectures:

buildTypes {
    debug {}
    release {}
}

targetPlatforms {
    x86 {
        architecture "i386"
    }
    x64 {
        architecture "x86_64"
    }
}

binaries.all {
    if (buildType == buildTypes.debug) {
        cppCompiler.args "-g"
    }
}

Four native binary variants will be produced: 'debugX86', 'releaseX86', 'debugX64' and 'releaseX64'.

As well as buildTypes and targetPlatforms, it's also possible to define variants based on toolChains and custom flavors.

Please check out the user guide section on variants for complete details on how to define the set of variants to be produced.

Improved native binary tool chain support incubating feature

Gradle 1.9 makes it easier to build native binaries using a variety of tool chains.

New features include:

A build file can define the set of tool chains used to build.

toolChains {
    visualCpp(VisualCpp)
    gcc(Gcc)
}

Visual Studio and Windows SDK installations are automatically discovered and do not need to be in the path

This means you can compile using the Visual C++ tools from the cygwin command prompt. If Visual Studio is installed into a non-standard location, you can provide the installation directory directly.

toolChains {
    visualCpp(VisualCpp) {
        installDir "C:/Apps/MSVS10"
    }
}

Use multiple versions of GCC within the same build invocation

Different Gcc tool chain instances can be added with different 'path' values.

toolChains {
    // Use GCC found on the PATH
    gcc4(Gcc)

    // Use GCC at the specified location
    gcc3(Gcc) {
        path '/opt/gcc/3.4.6/bin'
    }
}

Build binaries using the Clang compiler

toolChains {
    clang(Clang)
}

Better support for building binaries from C/C++/Assembler incubating feature

This release improves the support for building binaries from C, C++ and Assembly Language source code. Improvements include:

Be sure to check out the user guide section for even more details.

New 'assembler' and 'c' plugins provide separate language support.

In this release, the 'cpp' plugin now only provides support for compiling and linking from C++ sources. If your project contains C or Assembly language sources, you will need to apply the 'c' or 'assembler' plugins respectively.

By splitting the support for different languages into separate plugins, this release paves the way for adding more supported languages in the future.

To complement this change, the compilerArgs, assemblerArgs and linkerArgs on NativeBinary have been replaced with language-specific extensions.

Gradle 1.8 Gradle 1.9
compilerArgs "-W" cppCompiler.args "-W"
compilerArgs "-W" cCompiler.args "-W"
assemblerArgs "-arch", "i386" assembler.args "-arch", "i386"
linkerArgs "-no_pie" linker.args "-no_pie"
staticLibArgs "-v" staticLibArchiver.args "-v"

Note that the language-specific element is only present if the appropriate plugin has been applied. So the 'cCompiler' extension is only available if the 'c' plugin has been applied.

Source sets for a native component (executable or library) are automatically configured

In earlier versions, a native component was not automatically associated with any source sets. To simplify configuration, Gradle now creates and attaches the relevant source sets for every defined executable or library.

Gradle 1.8 Gradle 1.9
apply plugin: 'cpp'
sources {
    main {
        cpp {}
    }
}
executables {
    main {
        source sources.main.cpp
    }
}
apply plugin: 'cpp'
executables {
    main {}
}

This means that given a executable named 'main', a functional source set named 'main' will be created, with a language source set added for each supported language. So applying the 'assembler' plugin would result in the 'sources.main.asm' language source set being added, with the conventional source directory src/main/asm.

Note that conventional source directories eg: src/main/cpp and src/main/headers are now only applied if no source directories are explicitly configured. If you don't define any source directories, the conventions apply. If you wish to define custom source locations, then all of the source locations must be specified (not just those in addition to the convention).

Tooling API supports GradleBuild for all Gradle versions

In this release, the GradleBuild tooling model is now supported for all target Gradle versions supported by the tooling API. Previously, this model was only available for target Gradle versions 1.8 and later.

Fixed issues

Potential breaking changes

Renames in incubating BuildSetup plugin

Changes to incubating Native Binary support

External contributions

We would like to thank the following community members for making contributions to this release of Gradle.

We love getting contributions from the Gradle community. For information on contributing, please see gradle.org/contribute.

Known issues

Known issues are problems that were discovered post release that are directly related to changes made in this release.