Gradle Release Notes
Version 1.0-milestone-8
- New and Noteworthy
- Fixed Jira Issues
New and Noteworthy
New code quality plugins
Gradle now includes several new code quality plugins, thanks to a contribution by Andrew Oberstar:
Standalone Checkstyle and CodeNarc plugins
The existing code quality plugin has been split up into a separate Checkstyle plugin and CodeNarc plugin. These plugins also now allow you to specify which version of Checkstyle or CodeNarc you'd like to use for the analysis.
Dependency resolution
Offline switch for dependency resolution
Gradle 1.0-milestone-8 introduces an "\--offline" switch, that tells Gradle to always use dependency artifacts from the cache, regardless if they are due to be checked again. When running with \--offline, Gradle will not attempt to access the network to perform dependency resolution. If required artifacts are not present in the dependency cache, build execution will fail.
At this time, external scripts that are included via apply from: are not cached, so are not helped by \--offline. This is something we intend to address soon.
Refresh switch for dependency resolution
At times, the Gradle dependency cache can be out of sync with the actual state of the configured repositories. Perhaps a repository was initially misconfigured, or perhaps a "non-changing" module was published incorrectly. To refresh all dependencies in the dependency cache, use the new "\--refresh dependencies" option on the command line.
The "\--refresh dependencies" option tells Gradle to ignore all cached entries for resolved modules and artifacts. A fresh resolve will be performed against all configured repositories, with dynamic versions recalculated, modules refreshed, and artifacts downloaded. However, where possible Gradle will attempt to verify if the previously downloaded artifacts are valid before downloading again. This is done by comparing published SHA1 values in the repository with the SHA1 values for previously downloaded artifacts.
New user guide section on the dependency cache
This section describes in some detail the design and behaviour of the Gradle dependency cache.
Changing module (SNAPSHOT) artifacts are correctly downloaded when changed
In Gradle 1.0-milestone-7 there was an issue that meant Gradle did not always download the changed artifacts for a changing module, regardless of the cacheChangingModulesFor setting. This has been fixed in Gradle 1.0-milestone-8.
Before downloading a new copy of a changing module artifact, Gradle will check the published SHA1 key against the currently downloaded version. This means that SHA1 key files are essential to avoid Gradle downloading these artifacts on every build execution.
Support for NTLM proxy authentication
Gradle is now able to resolve dependencies when HTTP access is via a proxy that requires NTLM authentication via the standard http.proxyUser and http.proxyPassword system properties.
If your proxy requires NTLM authentication, you may need to provide the authentication domain as well as the username and password.
There are 2 ways that you can provide the domain for authenticating to a NTLM proxy:
- You can set the http.proxyUser system property to a value like <domain>/<username>.
- You can also provide the authentication domain via the http.auth.ntlm.domain system property.
Daemon improvements
- As usual, any improvements to the daemon also positively affect the Tooling API users. If you happen to embed Gradle, read on.
- User guide contains a brand new chapter on the gradle build daemon. Please give it a read if you haven't yet used the daemon or if you want to find out the details like: how to troubleshoot the daemon, where the daemon log lives or when exactly gradle forks new daemons.
- The daemon is now configurable via gradle.properties and system properties. Take a look at this section of the Gradle daemon chapter in the user guide. The new configurability includes turning the daemon 'on' by default, specifying the java home and jvm arguments (finally you can tweak daemon's memory settings\!), configuring the daemon idle timeout, etc. We may add more options in future.
- We've also fixed a couple of outstanding bugs related to the daemon.
Tooling API improvements.
Chapter on embedding Gradle.
It largely covers the fundamental ideas behind the Tooling API and I would really recommend to read that if you are into embedding Gradle. We've also added many samples to the Tooling API javadocs. Check out the chapter here or check out the javadocs for tooling API starting from its main entry point: GradleConnector.
Tooling Api thread safety.
We've fixed some outstanding problems with the Tooling API thread safety. Combined with some daemon fixes it increases the quality of the Tooling API.
Tooling API offers more configurability.
- The standard input. We're not great fans of interactive builds but if your build happens to ask questions, now you can use the Tooling API to drive it. By default, a dummy input stream that contains 0 bytes is used by the Tooling API.
- The java home. Now you can configure the java home for the Tooling API operation, be it running a build or acquiring some model. If you don't specify the java home, the usual default is used.
- The jvm arguments. If your build happen to need outrageous amounts of memory, now you can drive this build via Tooling API easily by bumping the memory accordingly via the jvm arguments. Alternatively, if you want to make sure your build does not take a lot of memory and you want to override the defaults (they are pretty generous) now you have a way of achieving that with the Tooling API.
See examples in javadocs for BuildLauncher or ModelBuilder.
Tooling API informs about the build environment.
It is possible to acquire information about the build environment like the java home, jvm arguments or the gradle version. The gradle version information is available on any target Gradle version. Complete build environment information is available for target gradle version > milestone-7. Take a look at information and samples in the docs for BuildEnvironment.
Improvements to signature generation
Some improvements have been made to the signing plugin to make it easier to configure builds that only need to generate signatures sometimes.
In almost all cases, it's as simple as:
signing {
required = !version.endsWith("SNAPSHOT")
}
When signing is not required and the signing configuration is missing (i.e. the necessarily credentials to generate signatures) any signing tasks will be skipped. For publication, this means that the signatures will just not be generated and uploaded. Likewise, when signing is not required the signPom() method that is used in maven deployments will not error if it cannot generate a signature.
For situations where you may not know until execution time if signing is required, you can assign a closure to the required property.
signing {
required = { gradle.taskGraph.hasTask(uploadArchives) && !version.endsWith("SNAPSHOT") }
}
Other Changes
Gradle Wrapper supports proxy authentication
The gradle wrapper now supports authenticated proxies via the standard JVM proxy properties ( http://gradle.org/docs/current/userguide/tutorial_this_and_that.html#sec:accessing_the_web_via_a_proxy). For this to work, add a gradle.properties file as described, either in the root directory of your project, or in your Gradle home directory.
Plugin and task implementation
Added @OutputDirectories and @OutputFiles annotations
These annotations are analagous to the task.outputs.dirs() and task.outputs.files() API methods. The annotations can be applied to any property whose type is compatible with Iterable<File> (e.g. FileCollection, List<File>).
For @OutputDirectories, each item is ensured to be created as a directory before the task executes. For @OutputFiles, each item's parent directory is ensured to be created before the task executes.
Added ExtensionContainer.add(name, type, args...)
This method of adding extensions results in an extension being added that itself is extensions aware. This will eventually replace the ExtensionContainer.add(String, Object) method.
Here's an example:
import org.gradle.api.plugins.ExtensionAware
class MyExtension {
String name
Project project
MyExtension(String name, Project project) {
this.name = name
this.project = project
}
}
project.extensions.add("foo", MyExtension, "foo", project)
project.foo.extensions.add("bar", MyExtension, "bar", project)
assert project.foo instanceof MyExtension
assert project.foo instanceof ExtensionAware
assert project.foo.bar instanceof MyExtension
assert project.foo.bar instanceof ExtensionAware
Reporting abstraction
Some new model elements have been introduced to provide a standardise way to model report generation. The javadoc for the new classes can be found here.
Tasks that generate reports implement the Reporting interface which allows configuration like the following:
codenarcMain {
reports {
xml.enabled = false
text {
destination "$build/codenarcMain.txt"
}
html {
enabled = true
}
}
}
At the moment, only the new code quality related tasks have been updated to this new mechanism.
Resolved
