With this release, the Gradle team moves into a more rapid release cycle, with a goal to release a new version of Gradle every 4-6 weeks. By increasing our release frequency, we aim to reduce the wait time for important bug fixes, as well as get new features out sooner.
Even with a short development cycle, this release still contains some important features and improvements. As well as fixing quite a few bugs, we've made incremental improvements to the new "Gradle TestKit" and enhanced the experience of developing Play applications using Gradle with continuous build.
In addition to this, this version of Gradle now makes it easier use GitHub or BitBucket to back an authenticated Maven repository, by adding support for preemptive HTTP authentication.
--continuousIf you generated your Gradle wrapper with Gradle 2.6, we strongly recommend you regenerate your gradle-wrapper.jar with Gradle 2.7. The new checksum validation feature added in 2.6 introduced a serious performance degradation in the Gradle wrapper. This issue affects the startup time for any gradle execution via this wrapper. This issue has been fixed in 2.7.
NOTE: This only affects wrappers generated by Gradle 2.6. If you generated your wrapper with a older version, you can still configure that wrapper to point to Gradle 2.6 without issue.
When authenticating to Maven or Ivy repositories over HTTP/HTTPS, Gradle will attempt to use all supported authentication schemes to connect (NTLM, Kerberos, Digest, Basic). This release allows for the explicit selection of authentication schemes that should be used, allowing a build author to prevent the use of an unwanted authentication scheme.
The authentication schemes to use are specified by adding them to the new authentication element for a repository.
For example, to configure a repository to use only digest authentication:
repositories {
maven {
url 'https://repo.mycompany.com/maven2'
credentials {
username 'user'
password 'password'
}
authentication {
digest(DigestAuthentication)
}
}
}Currently, only BasicAuthentication and DigestAuthentication schemes can be explicitly configured, and only for HTTP transport. More details can be found in the Gradle User Guide.
Building on the new support for selecting authentication schemes, Gradle will now send preemptive HTTP authentication for repositories configured to use BasicAuthentication.
Gradle will normally submit HTTP credentials only when a server responds with an authentication challenge (401-UNAUTHORIZED). This avoids sending unencrypted credentials when not required. However, in some cases a server will respond with a different response for resources requiring authentication (e.g. GitHub will return a 404-NOT-FOUND). This causes dependency resolution to fail.
To get around this behavior, credentials may be sent to the server preemptively. Where a repository is explicitly configured to use the BasicAuthentication scheme, Gradle will send credentials preemptively for every request:
authentication {
basic(BasicAuthentication) // enable preemptive authentication
}The previous release of Gradle introduced the Gradle TestKit for functionally testing Gradle plugins.
This release extends the existing TestKit feature set by adding Test execution isolation. Test execution is now performed in an isolated "working space" in order to prevent builds under test inheriting any environmental configuration from the current user.
The TestKit uses dedicated, reusable Gradle daemon processes; after executing all functional tests for a build, these daemon processes are stopped.
--continuous incubating featureThe initial release of the Gradle Play plugin allowed Play applications to be developed in a continuous build, automatically reloading resources and application classes on rebuild. However, when a build failure occurred, Gradle would simply leave the existing application running.
When running with Gradle 2.7, the running Play application will reload on build failure, showing any build failure message in the browser.
In this release, the 'play' plugin has been updated to support Play 2.4, and includes support for the new injected routes generator.
You can configure the routes compiler to use the injected routes generator, by using a new configuration option on the play component:
model {
components {
play {
injectedRoutesGenerator = true
}
}
}By default, Gradle will use the static routes generator.
Managed types now support properties of any primitive type (boolean, byte, char, short, int, long, float and double), as well as any of their boxed types (respectively Boolean, Byte, Character, Short, Integer, Long, Float and Double). Primitive boolean properties can be declared with either a classic getter or an is-style getter. e.g.
@Managed
interface ManagedType {
boolean getEnabled()
void setEnabled(boolean enabled)
boolean isActive()
void setActive(boolean active)
int getCount()
void setCount(int value)
}It is possible for a single boolean property to have both a get and is getter.
This release introduces new dependency management features for JVM components, an important step toward full variant-aware dependency resolution. This feature is built upon the new rule based model configuration and requires you to use the new jvm-component plugin:
plugins {
id 'jvm-component'
id 'java-lang'
}A defined JvmLibrarySpec can declare API dependencies on any other locally-produced libraries. This includes other JvmLibrarySpec instances in the same Gradle project, and JvmLibrarySpec components declared in other projects of a multi-project build.
model {
components {
main(JvmLibrarySpec) {
targetPlatform 'java7'
targetPlatform 'java8'
sources {
java {
dependencies {
library 'commons'
}
}
}
}
commons(JvmLibrarySpec) {
targetPlatform 'java7'
}
}
}For a JvmLibrarySpec that is configured to produce multiple variants for different platforms, Gradle will generate and resolve a compatible binary variant of the depended-on library. In the example above, Gradle will produce 2 JAR variants of the 'main' library component, one each for JDK 1.7 and JDK 1.8. Both of these will be compiled against the JDK 1.7 Jar variant of the 'commons' library.
More information about this incubating feature can be found in the User Guide.
ANTLR generated sources and package structureANTLR generated sources is now calculated from package information in the grammar files. (This fixes a regression introduced in Gradle 2.2).ANTLR3 and ANTLR4 generated sources is now relative to the path of the grammar in the ANTLR grammar folder.This release fixes a bug where generating the Eclipse classpath for projects with a shared directory for source and resource files using includes and excludes declarations could cause problems (see GRADLE-3335 for details). This fix changes the behaviour of applying exclude/include filters to the source directory, which may result in a different set of directories in the generated Eclipse classpath.
For an exclude to be applied to the source folder in the Eclipse classpath, that exclude must be declared for both the java and resources sourceSets. This is only important in the case of overlapping source and resource directories.
We would like to thank the following community members for making contributions to this release of Gradle.
Sets in ProjectDependencyArtifactIdExtractorHackWe 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.