This release is a 7.0 milestone. This is a preview of what Gradle 7.0 may look like.
Milestone releases are unstable like nightly releases, but we are releasing it to gather early feedback on potential changes in Gradle 7.0.
If you run into problems with this milestone, please report your feedback on GitHub.
Some features in this milestone may not make it to the first release candidate and future milestones may introduce new features.
We would like to thank the following community members for their contributions to this release of Gradle:
Aidar Nugmanoff, Martin d'Anjou, Till Krullmann, Andreas Axelsson, Pedro Tôrres, Stefan Oehme, Jeff, Rene Groeschke, Niels Doucet, Tobias Hermann, Rishaba-Jain, Jerome Dochez, Vitaly Polonetsky, Naoki Ando, Ståle Undheim.
Switch your build to use Gradle 7.0-milestone-3 by updating your wrapper:
./gradlew wrapper --gradle-version=7.0-milestone-3
See the Gradle upgrade guide to learn about deprecations, breaking changes and other considerations when upgrading to Gradle 7.0-milestone-3.
For Java, Groovy, Kotlin and Android compatibility, see the full compatibility notes.
This release contains further improvements for incremental development — the part of the software development process where you make frequent small changes.
In an incremental build, input and output files are checked to determine what needs to be rebuilt. This feature typically saves a lot of time; however, it adds some I/O overhead, which can be noticeable in large projects when not much has changed since the previous build.
In Gradle 6.7 we've introduced file-system watching as an opt-in production-ready feature. When enabled, it allows Gradle to keep what it has learned about the file system in memory during and between builds instead of polling the file system on each build. This significantly reduces the amount of disk I/O needed to determine what has changed since the previous build.
This feature is now enabled on all supported platforms.
Read more about this feature and its impact on the Gradle blog!
This release contains performance improvements for doing incremental development on Android builds, especially when using Jettifier.
For example, assembleDebug
for a non-abi change on the Santa Tracker Android project improved by 12% compared to Gradle 6.8:
File system watching and configuration caching is enabled for the comparison.
You can find the performance test project here.
With previous Gradle versions there were two options to run Gradle builds on the new Macs equipped with the M1 chip:
With Gradle 7.0 there is no need to sacrifice functionality or performance, as every feature is now fully supported using a native ARM JDK, too.
In order to support JDK 16, Gradle has been upgraded to use Groovy 3. Groovy 3 comes with a brand-new parser and host of other new features and capabilities.
In order to learn more about the improvements and new features in Groovy, please refer to their release notes. Please refer to the Gradle upgrade guide to learn more about upgrading your build and plugins to be compatible with Groovy 3.
Gradle now supports running on and building with Java 16.
buildSrc
projectIn earlier Gradle versions, the mere presence of a buildSrc
directory was enough to trigger Gradle to execute all buildSrc
tasks and to add the resulting buildSrc.jar
to the buildscript class path. Gradle will now ignore an empty buildSrc
directory, and will only generate a buildSrc.jar
if build files and/or source files are detected.
This has two benefits when an empty buildSrc
directory is detected:
:buildSrc:*
tasks will not be needlessly executed.buildSrc.jar
will not be added to the buildscript class path, avoiding cache misses that this can cause.Until now, the plugins { }
block only supported fixed versions for community plugins. All version string notations Gradle supports are now accepted, including +
or latest.release
.
Gradle employs a number of optimizations to ensure that builds are executed as fast as possible. These optimizations rely on the inputs and outputs of tasks to be well-defined. Gradle already applies some validation to tasks to check whether they are well-defined.
If a task is found to be invalid, Gradle will now execute it without the benefit of parallel execution, up-to-date checks and the build cache. For more information see the user manual on runtime validation.
One of the potential problems now flagged is a task that consumes the output produced by another without declaring an explicit or inferred task dependency. Gradle now detects the missing dependency between the consumer and the producer and emits a warning in that case. For more information see the user manual on input and output validation.
The Java plugins now recognizes the org.gradle.jvm.environment
attribute during dependency resolution. This allows libraries to clearly distinguish variants optimized for standard-jvm
and android
.
Developing plugins as part of a composite build was so far only possible for project plugins. Settings plugins always had to be developed in isolation and published to a binary repository.
This release introduces a new DSL construct in the settings file for including plugin builds. Build included like that can provide both project and settings plugins.
pluginManagement {
includeBuild("../my-settings-plugin")
}
plugins {
id("my.settings-plugin")
}
The above example assumes that the included build defines a settings plugin with the id my.settings-plugin
.
Library components produced by builds included though the pluginManagement
block are not automatically visible to the including build. However, the same build can be included as plugin build and normal library build:
pluginManagement {
// contributes plugins
includeBuild("../project-with-plugin-and-library")
}
// contributes libraries
includeBuild("../project-with-plugin-and-library")
This distinction reflects what Gradle offers for repository declarations - repositories are specified separately for plugin dependencies and for production dependencies.
Gradle 7 recognizes the org.gradle.plugin.api-version attribute during plugin resolution. This allows plugin authors to publish different variants of their plugins for different Gradle versions. This user manual section describes how the new attribute can be used with feature variants to add additional variants to a plugin.
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.
Compiling, testing and executing Java modules is now a stable feature. It is no longer required to activate the functionality using java.modularity.inferModulePath.set(true)
.
Dependency verification is promoted to a stable feature.
Java Toolchains is promoted to a stable feature.
Changing the priority of the daemon process with --priority
is now a stable feature.
In Gradle 7.0 we moved the following classes or methods out of incubation phase.
Core
Dependency management
IDE
Tooling API
Java Ecosystem
gradle-enterprise
: PluginDependencySpecPlugin development
org.gradle.api.distribution.Distribution.getDistributionBaseName()
Known issues are problems that were discovered post release that are directly related to changes made in this release.
We love getting contributions from the Gradle community. For information on contributing, please see gradle.org/contribute.
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.