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.
New and noteworthy in Gradle 2.7
Selection of HTTP authentication schemes incubating feature
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.
Support for preemptive HTTP authentication incubating feature
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)
}
Gradle TestKit executes tests within an isolated environment incubating feature
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.
Play application displays build failures when running with --continuous incubating feature
The 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.
Dependency management for JVM components incubating feature
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.