The Gradle team is pleased to announce Gradle 2.13. This release brings significant performance improvements, more convenience for testing Gradle plugins, customization options for the Checkstyle and FindBugs reports and OpenPGP subkey support for the Signing plugin.
We've achieved performance improvements during Gradle's configuration and execution phase, where we have measured up to 25% improvements to build time in our performance tests. No changes to your build script are necessary to start taking advantage of these improvements.
We've improved Gradle TestKit, so that plugin authors no longer need to add boilerplate to their build scripts when testing their plugins. The development plugin automatically adds the necessary configuration to make it easier to test Gradle plugins.
The Gradle Community has contributed many fixes and new features in this release. The Checkstyle and FindBugs plugins now allow you to customize their HTML reports with stylesheets. The Signing plugin supports OpenPGP subkeys, so you can keep your master signing keys safely off your CI server. These are just some of the great contributions we've received.
As we announced in our newsletter, we're introducing a new way of putting multiple Gradle builds together. We're calling this feature Composite Build. A composite build allows you to combine multiple Gradle builds and replace external binary dependencies with project dependencies as if you were using a single multi-project build. For projects that use multiple distinct Gradle builds, this will allow you to mix and match your separate builds into one build in a very flexible way. This will work from the command-line as well as from your IDE.
Upgrade to Gradle 2.13 and let us know what you think.
Project.findProperty() method for safer property lookupsDelete/project.delete() no longer follows symlinksHere are the new features introduced in this Gradle release.
A number of performance improvements have been targeted at Gradle's execution phase. This is part of the build lifecycle where Gradle executes the tasks defined in a build.
Improvements introduced in this release:
gradle.properties exists has been removed.Performance tests that run as part of Gradle's build pipeline have demonstrated up to a 25% improvement in build time. For example, the build time for a full assemble of a 500 project build has been reduced by 10% and a partial assemble of the same 500 project build has been reduced by 18%. The time for assemble and test of a 25 project build has been reduced by 25%.
No change is required to build scripts to leverage these performance improvements.
Gradle 2.6 introduced the Gradle TestKit, which made it easier to thoroughly test Gradle plugins and build logic. The TestKit has improved and matured with each subsequent Gradle release.
The Java Gradle Plugin Development Plugin now makes the plugin-under-test's implementation classpath discoverable at test time automatically. This means you need less manual build configuration in order to test your plugin.
If you build your plugin with Gradle 2.13, you no longer need to manually inject your plugin's classpath in tests if you are testing against Gradle 2.8 or newer. If you need to test against a version of Gradle older than 2.8, you will still need to include your plugin's classpath in the buildscript {} block.
See the TestKit chapter in the Gradle User Guide for more information and examples of using this new feature.
Up until this release, the only way to retrieve models and execute tasks from the Tooling API was through the ProjectConnection API. This API was limited to a single connection to a single project in a build (regardless if the build was multi-project or single-project). This makes it difficult and expensive to retrieve information about each project in a build.
For Composite Build, we need a way to retrieve multiple models from a group of Gradle builds (each of which may be a single project or multiple projects). We also need a way to execute tasks in the context of a composite. In the future, we'll use the composite context to identify dependency substitutions that should be made and correctly wire together task dependencies. Eventually, composite builds will allow you to use different versions of Gradle in each build and execute tasks across projects in the composite from the command-line.
We have introduced a new GradleConnection API, which will eventually replace ProjectConnection.
We have also introduced ProjectIdentifier and BuildIdentifier model types. These types will be used to correlate results from a GradleConnection back to the appropriate Gradle build or Gradle project.
GradleConnector remains the main entry point into the Tooling API. Samples of using the GradleConnection API are available in the Gradle distribution (samples/tooling-api/composite-.*) and in the Javadoc for GradleConnection.
The HTML reports generated by the Checkstyle and FindBugs plugins can now be customized with XSLT stylesheets.
Sample stylesheets are available from each tool's website.
See the documentation for the Checkstyle and FindBugs plugins for more details.
This was contributed by Pierre-Etienne Poirot.
Groovy 2.4.6 adds two new flags to its Groovydoc command.
Enabling these flags will cause Groovydoc to produce documentation pages without a timestamp or Groovy version. This means that it will be harder to determine when a page was generated or which version of Groovy was used to produce the pages, but documentation pages will remain unchanged across Groovy versions unless the content really changes.
You must be using Groovy 2.4.6 to use these flags. When using the groovy plugin, you can enable the flags as follows:
dependencies {
compile 'org.codehaus.groovy:groovy-all:2.4.6'
}
groovydoc {
noTimestamp = true
noVersionStamp = true
}The flags are ignored for older versions of Groovy prior to 2.4.6.
This was contributed by Paul King.
OpenPGP supports a type of subkey, which are like normal keys, except they're bound to a master key pair.
These subkeys can be stored independently of master keys. OpenPGP subkeys can also be revoked independently of the master keys, which makes key management easier. You only need the subkey for signature operations, which allows you to deploy only your signing subkey to a CI server.
The Signing plugin now supports subkeys, see the documentation for more details.
This was contributed by Marcin Zajączkowski.
Project.findProperty() method for safer property lookupsOften builds fail when a property cannot be found. Before the Project.findProperty() method, build script authors often had to write code like the following to provide a default value for properties that might not have been set.
def myValue = hasProperty('myKey') ? getProperty('myKey') : 'defaultValue'The new Project.findProperty() method will return null if the property is not found, so the above check can be simplified to:
def myValue = findProperty('myKey') ?: 'defaultValue'This feature was contributed by Marcin Zajączkowski
Delete/project.delete() no longer follows symlinksThe Delete task will no longer follow symlinks by default and project.delete(paths) will not follow symlinks at all. This was done to prevent issues where Gradle would attempt to delete files outside of Gradle's build directory (e.g. NPM installed in a user-writeable location).
This was contributed by Ethan Hall.
The Gradle User Guide now includes clickable links to section headers.
This was contributed by Peter Ledbrook.
As described above, deleting files will no longer follow symlinks by default.
Previous versions of Gradle would follow symlinks when deleting files. If you need the Delete task to follow symlinks set followSymlinks = true. If you need project.delete('somepath') to follow symlinks, replace it with:
project.delete {
delete 'somepath'
followSymlinks = true
}Task input properties now correctly follow the JavaBean specification. For most properties, this will have no effect. For some properties that have unusual capitalization, you may need to use a different name when accessing the property from the Map of input properties. Input properties are now addressed with the same names in validation error messages, DSL and through getInputs().getProperties().
For example:
getcFlags and you have marked it as an @Input,
cFlags according to the JavaBean specification.cFlags or getcFlags() in the DSL.getInputs().getProperties().get("cFlags") or inputs.properties.cFlags.getCFlags and you have marked it as an @Input,
CFlags according to the JavaBean specification.CFlags or getCFlags() in the DSL.getInputs().getProperties().get("CFlags") or inputs.properties.CFlags.cFlags (e.g., getInputs().getProperties().get("cFlags") or inputs.properties.cFlags).getURL() are now found with getInputs().getProperties().get("URL") or inputs.properties.URL instead of the erroneous uRL.Most builds are unlikely to be using the names of the properties available from getInputs().getProperties().
The JaCoCo plugin uses JaCoCo 0.7.6 by default.
To downgrade to the previous version:
jacoco {
toolVersion = "0.7.1.201405082137"
}This was contributed by Evgeny Mandrikov.
Gradle now bundles Apache Commons Collections 3.2.2.
This is an internal dependency, but buildSrc plugins may inadvertently use classes from this dependency.
This was upgraded to fix a security vulnerability.
This was contributed by Jeffrey Crowell.
Gradle now bundles Apache Ant 1.9.6 instead of Apache Ant 1.9.3.
This was contributed by Alpha Hinex.
setTestNameIncludePattern() renamed to setTestNameIncludePatterns()The incubating setTestNameIncludePattern() method on the Test API has been renamed setTestNameIncludePatterns to better reflect the fact that it can accept multiple patterns.
We would like to thank the following community members for making contributions to this release of Gradle.
getFile() and filtersnoTimestamp and noVersionStamp propertiesDEFAULT_JVM_OPTS after APP_HOME in application pluginpublic keywords from build.gradletools.jar is not foundProject.findProperty method, fix a test which was failing against the OpenJDKWe 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.