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.
Groovy or a Scala projectHere are the new features introduced in this Gradle release.
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.
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.
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
Groovy or a Scala projectThe 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.
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
}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.
Gradle 1.9 makes it easier to build native binaries using a variety of tool chains.
New features include:
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.
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.
Unable to retrieve the issue information. You may not be connected to the Internet, or there may have been an error.
compilerArgs and linkerArgs with cppCompiler.args and linker.args.gpp-compiler plugin was renamed to gcc. Class name was changed to GccCompilerPlugin.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.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 are problems that were discovered post release that are directly related to changes made in this release.
Unable to retrieve the issue information. You may not be connected to the Internet, or there may have been an error.