Gradle now includes several new code quality plugins, thanks to a contribution by Andrew Oberstar:
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.
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.
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.
This section describes in some detail the design and behaviour of the Gradle dependency cache.
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.
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:
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.
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.
See examples in javadocs for BuildLauncher or ModelBuilder.
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.
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") }
}
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.
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.
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
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.