Gradle Release Notes

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:

• groovy-library creates a simple Groovy project with Spock as the testing framework.
• scala-library creates a simple Scala project with scalatest as the testing framework.

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
• Visual Studio and Windows SDK installations are automatically discovered and do not need to be in the path
• Use multiple different versions of GCC within the same build invocation
• Build binaries using the Clang compiler

toolChains {
    visualCpp(VisualCpp)
    gcc(Gcc)
}

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

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

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

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:

• Separate plugins for C, C++ and Assembler support
• Separate compiler options for C++ and C sources
• Automatic configuration of source sets for native components

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

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

apply plugin: 'cpp'
executables {
    main {}
}

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

• The ´BuildSetup´ task was renamed to ´InitBuild´.
• The plugin ´build-setup was renamed to ´build-init´.
• The task ´setupBuild´ provided by the auto-applied BuildInit plugin was renamed to ´init´.
• The package name for the ´build-init´ related classes has changed from ´org.gradle.buildsetup´ to ´org.gradle.buildinit´.

Changes to incubating Native Binary support

• The 'cpp' plugin no longer automatically adds support for C and Assembler sources.
• Replaced compilerArgs and linkerArgs with cppCompiler.args and linker.args.
• Renamed and restructure package organisation for domain, plugin and task classes. If you are referencing these classes directly you may need to update your build script for this reorganisation.
• The temporary file generated for compiler/linker input has been renamed from "compiler-options.txt" to "options.txt".
  • This file now only contains file inputs to the tool - all other options are supplied directly via the command line.
• Object files generated from the assembly of Assembler sources are no longer named ' .s.o'.
• Renamed method: BuildableModelElement.dependsOn() -> BuildableModelElement.builtBy()
• The gpp-compiler plugin was renamed to gcc. Class name was changed to GccCompilerPlugin.
• The conventional source directories eg: src/main/cpp and src/main/headers are only applied if no source directories are explicitly configured. If you wish to define custom source locations, you must define all of the source locations.

External contributions

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

• John Engelman
  • Existence of pom file requires that declared artifacts can be found in the same repository (GRADLE-2034).
  • Fix publishing to Maven Local to follow Maven rules (GRADLE-2762).
• Jean-Baptiste Nizet - Added an HTML dependency report.
• Valdis Rigdon - Adds the ability to specify xml:withMessages, text, or emacs for the FindBugs report.
• Robert Kühne
  • Documentation fixes.
  • Fix a regression when adding Action instances to tasks (GRADLE-2774).
• Mark Petrovic - Cucumber test report file formation is failing (GRADLE-2739).
• Bryan Keller - JAR manifest should be first entry in a archive file (GRADLE-2886).

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.