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:
Martin d'Anjou, Till Krullmann, Andreas Axelsson, Pedro Tôrres, Stefan Oehme, Niels Doucet.
Switch your build to use Gradle 7.0-milestone-1 by updating your wrapper:
./gradlew wrapper --gradle-version=7.0-milestone-1
See the Gradle upgrade guide to learn about deprecations, breaking changes and other considerations when upgrading to Gradle 7.0-milestone-1.
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. These performance improvements are more pronounced for Android builds.
For example, assembleDebug
for a non-abi change on the Santa Tracker Android project improved by 15% compared to Gradle 6.7:
File system watching and configuration caching is enabled for the comparison.
You can find the performance test project here.
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.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.
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.
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.