Gradle Release Notes

Version 7.0-milestone-2

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, Jeff, Rene Groeschke, Niels Doucet, Ståle Undheim.

Table Of Contents

Upgrade Instructions

Switch your build to use Gradle 7.0-milestone-2 by updating your wrapper:

./gradlew wrapper --gradle-version=7.0-milestone-2

See the Gradle upgrade guide to learn about deprecations, breaking changes and other considerations when upgrading to Gradle 7.0-milestone-2.

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.

File system watching is enabled by default

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!

Android performance improvements

This release contains performance improvements for doing incremental development on 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.

Groovy 3 upgrade

Gradle has been upgraded to use Groovy 3. Groovy 3 comes with a brand new parser (code-named Parrot) 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. While we're integrating the various improvements of Groovy into the Gradle codebase, you might experience unexpected problems related to the Groovy classpath, the Groovy DSL and the usage of withGroovyBuilder. If you experience any issues, please report an issue for us to look into this before the final release.

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:

Using dynamic versions in the plugins block

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.

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.

Improved support for libraries with standard JVM and Android variants

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.

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.

Support for plugins with multiple variants

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.

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.