The Gradle team is excited to announce Gradle 5.1.
This release features repository to dependency matching, production-ready configuration avoidance APIs, Gradle Kotlin DSL 1.1, and more.
Read the Gradle 5.x upgrade guide to learn about breaking changes and considerations for upgrading from Gradle 5.0. If upgrading from Gradle 4.x, please read upgrading from Gradle 4.x to 5.0 first.
We would like to thank the following community contributors to this release of Gradle: Mike Kobit, Kent Fletcher, Niklas Grebe, Jonathan Leitschuh, Sebastian Schuberth, Dan Sănduleac, Olivier Voortman, Alex Saveau, and Till Krullmann.
NOTE: Gradle 5.1 has had one patch release. You should use the latest patch release (5.1.1).
Switch your build to use Gradle 5.1.1 by updating your wrapper properties:
./gradlew wrapper --gradle-version=5.1.1
Standalone downloads are available at gradle.org/releases.
It is now possible to match repositories to dependencies, so that Gradle doesn't search for a dependency in a repository if it's never going to be found there.
Example:
repositories {
maven {
url "https://repo.mycompany.com"
content {
includeGroupByRegex "com\\.mycompany.*"
}
}
}This filtering can also be used to separate snapshot repositories from release repositories.
Look at the user manual for more details.
--groupInstead of listing all available tasks, gradle tasks can now show only the tasks belonging to a particular group. This makes it easier to find tasks in builds with many available tasks.
This feature was contributed by Alex Saveau.
It's now possible to target multiple architectures when building C++ projects using the targetMachines property:
application {
targetMachines = [machines.linux.x86, machines.linux.x86_64, machines.windows.x86_64]
}When the build task is executed, Gradle will build all architectures associated with the current operating system. If a target machine isn't specified, Gradle will target the operating system and architecture of the host machine.
The target operating system and architecture is also used by Gradle's dependency management engine to publish and resolve compatible artifacts when C++ projects utilize binary dependencies.
validateTaskPropertiesCacheable tasks are validated stricter than non-cacheable tasks by the validateTaskProperties task, which is added automatically by the java-gradle-plugin. For example, all file inputs are required to have a normalization declared, like e.g. @PathSensitive(RELATIVE). This stricter validation can now be enabled for all tasks via validateTaskProperties.enableStricterValidation = true.
plugins { } blockThe plugins { } block in build scripts can now be used to refer to plugins defined in included builds. In previous versions of Gradle, this was possible but required some additional boiler-plate code in the settings file. This boiler-plate is now no longer required.
This change makes it super easy to add a test build for a Gradle plugin and streamlines the process of implementing a Gradle plugin. You can also use this feature to conveniently work on changes to a plugin and builds that use that plugin at the same time, to implement a plugin that is both published and used by projects in the same source repository, or to structure a complex build into a number of plugins.
Using the plugins { } block also makes the Gradle Kotlin DSL much more convenient to use.
You can find out more about composite builds in the user manual.
This release includes a lazy MapProperty type which allows efficient configuration of maps in the Gradle model, for example in a project extension or task property.
See the user manual for more details.
A convention method is now available for property types, which allows the convention for a property to be specified. The convention is a value that is used when no value has been explicitly configured for the property.
See the user manual for more details.
@Option on a task property of type Property<T>The @Option annotation can now be attached to a task property of type Property<T>, to allow the user to specify the property value using a command-line option. Curently, this support is limited to single value properties.
The following Tooling API types reported as part of ProgressEvents to registered ProgressListeners have been enhanced to include additional information:
TaskOperationDescriptor now includes the identifier of the plugin that registered the task and its dependencies.TaskExecutionResult now includes the list of reasons why a task was executed and whether it was executed incrementally.JavaCompileTaskOperationResult is a new subinterface of TaskOperationResult for JavaCompile tasks that includes information about the used annotation processors.Additional operation types that were previously only available as generic progress events now use their own dedicated interfaces:
org.gradle.tooling.events.configuration), including configuration times of applied plugins in ProjectConfigurationOperationResultorg.gradle.tooling.events.work)org.gradle.tooling.events.transform)The additional data and the new operation types are only available if the version of Gradle that is running the build is 5.1 or above.
Promoted features are features that were incubating in previous versions of Gradle but are now supported and subject to backwards compatibility. See the User manual section on the “Feature Lifecycle” for more information.
The following are the features that have been promoted in this Gradle release.
In a recent blog post, we described a new API for creating and configuration Task instances that allow Gradle to avoid creating and configuring tasks that do not need to be executed.
In this release, we now recommend that you use this new API when working with tasks in your plugins. We've updated our Gradle Guide for implementing plugins to use this new API.
By default, the Kotlin DSL uses the new APIs.
"Old style" task declarations in the Groovy DSL continue to be eager and force creation/configuration of any tasks created this way.
// "Old style" task declaration uses Task create API. This always creates a task.
task myTask(type: MyTask) {
// This is always called
}In the Groovy DSL, to use the new API:
tasks.register("myTask", MyTask) {
}The existing API is not deprecated in this release, but as builds transition to the new API, we will consider deprecating the API in a future release.
Previously, only exclude rules directly declared on published configurations (e.g. apiElements and runtimeElements for the java component defined by the Java Library Plugin) were published in the Ivy descriptor and POM when using the Ivy Publish Plugin or Maven Publish Plugins, respectively. Now, inherited exclude rules defined on extended configurations (e.g. api for Java libraries) are also taken into account.
Features that have become superseded or irrelevant due to the natural evolution of Gradle become deprecated, and scheduled to be removed in the next major Gradle version. See the User guide section on the “Feature Lifecycle” for more information.
The following are the newly deprecated items in this Gradle release. If you have concerns about a deprecation, please raise it via the Gradle Forums.
classes and classpath on ValidateTaskPropertiesThere should not be setters for lazy properties like ConfigurableFileCollections. Use setFrom instead.
validateTaskProperties.getClasses().setFrom(fileCollection)
validateTaskProperties.getClasspath().setFrom(fileCollection)See the Gradle 5.x upgrade guide to learn about breaking changes and considerations when upgrading to Gradle 5.1.
We would like to thank the following community members for making contributions to this release of Gradle.
@Deprecated annotations to ProjectLayout methods (gradle/gradle#7344)WindowsResourceCompile to use Provider API (gradle/gradle#7432)AbstractArchiveTask task types (gradle/gradle#7435)MapProperty (gradle/gradle#6863)We 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.
If you find a problem with this release, please file a bug on GitHub Issues adhering to our issue guidelines. If you're not sure you're encountering a bug, please use the forum.
We hope you will build happiness with Gradle, and we look forward to your feedback via Twitter or on GitHub.