Gradle Release Notes

Version 7.0-milestone-1

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.

Table Of Contents

Upgrade Instructions

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.

Performance improvements for incremental development

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:

:santa-tracker:assembleDebug with non-abi change performance improvements

File system watching and configuration caching is enabled for the comparison.

You can find the performance test project here.

Ignore empty buildSrc project

In 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:

Build reliability improvements

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.

Disable optimizations for validation problems

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.

Validate missing dependencies between tasks

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.

Plugin development improvements

Using included builds for local plugins

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.

Java Module Support

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

Dependency verification is promoted to a stable feature.

Java Toolchain

Java Toolchains is promoted to a stable feature.

Changing the priority of the daemon process

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.

Fixed issues

Known issues

Known issues are problems that were discovered post release that are directly related to changes made in this release.

External contributions

We love getting contributions from the Gradle community. For information on contributing, please see gradle.org/contribute.

Reporting Problems

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.