Original link: gradle.org/whats-new/g…

Gradle 7.0 has been released for some time now. Let’s take a look at some of the interesting features from Gradle 6.0 to 7.0.

  • Speed up incremental compilation
  • Make your build more secure by verifying the integrity of build dependencies.
  • Support the use ofJava 16The development of
  • useincluded buildsSimplify the build
  • Reduced through new dependency management featuresMulti-ProjectThe maintenance cost of the build
  • Use the latest versionGroovyandKotlinThe development of

Performance optimization

fasterup-to-datecheck

Fast feedback from local incremental compilation is critical to improving development efficiency. File system monitoring determines which files have changed by reducing themIOOperation to improve incremental compilation speed



As ofGradle 7.0, including the most recent versionWindows.LinuxandMacOSThis optimization is enabled by default on all supported operating systems.

For more details and principles on file system monitoring, see: Introducing File System Watching

To speed up thekotlin DSLScript compilation speed

Gradle 7.0 can compile Kotlin DSL build scripts faster and with less memory, i.e. KTS. Previously, when we modified the buildsrc code, most of the cache was invalidated, triggering a complete recompilation. Modifying the KTS plug-in in Buildsrc skips compilation of unaffected build script files entirely. So when we change buildsrc, KTS plug-ins will compile much faster than Gradle plug-ins in Gradle7.0

To improvebuild cacheshooting

Gradle7.0 improves build cache hit ratio by selectively ignoring changes that do not affect system behavior such as empty file directories, Spaces and comments in properties files

supportconfiguration cache(Experimental properties)

Gradle already supports build cache, but before any Task can be executed, Gradle needs to go through the Configuration phase. Configuration is currently executed on every build and can cause significant delays, especially in large projects.

Configuration Cache improves build performance by caching the results of the Configuration phase. Using the Configuration cache, Gradle can skip the Configuration stage completely to speed up builds when there are no changes that affect the configuration.

In addition, useconfiguration cacheMore work is done in parallel, and construction can be acceleratedexecutionPhase.

Please note that this feature is currently experimental, not enabled by default, and sinceGradle 7.0Not all core plug-ins are supported.

For details about configuration cache, see Configuration Cache

Faster AD hoc build speed

Sometimes we do AD hoc builds where the AD hoc build machine needs to re-download all dependencies, which can be costly. Gradle 7.0 can speed up AD hoc builds by reusing dependency Cache across machines.

redirectdependency cache

Dependency Cache defaults to $GRADLE_HOME/caches/modules-2, and the cache directory can be relocated to another directory or host to cache dependencies. Builds using Dependency Cache will not need to access the network to download dependencies if they have already been downloaded when redirected to a new location or host

It is important to note that a compatible Gradle version should be used to create and use caches. You can browse the documentation for more details

Shared read-onlydependency cache

Gradle provides the ability to share dependency Cache between multiple Gradle instances. This allows us to create a shared directory that contains all the dependencies needed for the build.

  • eachGradleInstances can all access the shared read-only dependency cache, which avoids redundant downloads between builds.
  • Can be found inGradleThis cache is securely shared between instances without creating separate copies of it.

Ease of use and new feature optimization

JVMToolchain support for projects

By default, Gradle uses the same Version of Java to run Gradle itself and build JVM projects, but this is not always applicable. Building on different development machines and CI servers may use different versions of Java, which can cause unexpected problems. In addition, you may want to build your project using a version of Java that is incompatible with running Gradle.

Gradle provides a toolchain that allows you to set the Java version of your project to build:

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(14)}}Copy the code

GradleWill check localJavaIf no one locally matches the build requirementsJavaVersion,GradleWill be taken fromAdoptOpenJDKThe website downloads matchJDK.

For detailed use of JVM project Toolchains support, see Toolchains for JVM Projects

Process user credentials

Builds sometimes require users to provide credentials. For example, Maven libraries may require authentication in order to publish an AAR, and it is good practice to keep credentials outside the build script.

Gradle provides an API that provides Gradle properties to provide credentials to make it easier to use. These properties can be used as command-line arguments, environment variables, or key-value pairs in a gradle.properties file that can then be read in a build script. Gradle also introduces fast failure behavior when it knows that a build will at some point require credentials and lack them.

For an example of using Gradle user Credentials, see Publishing Credentials Sample

Support to performincluded buildsIn the task

Gradle allows users to execute tasks from included builds directly from the command line. For example, if your build included my-other-project and it had a subproject sub with Task Foo, you could execute foo with the following command:

gradle :my-other-project:sub:foo
Copy the code

Only one dependency lock file is retained

Dependency locking is a mechanism to ensure reproducible builds when using dynamically dependent versions. Gradle 7.0 uses a single lock file to lock dynamic dependencies to the version they parse. Gradle7.0 automatically migrates to a single locked file. Gradle7.0 automatically migrates to a single locked file.

Safety optimization

Depend on the validation

Our projects often use a large number of external dependencies, which puts them at risk of using untrusted code. For example, someone might accidentally introduce malicious code through pass-through dependencies. Similarly, your build scripts themselves can be attacked by executing malicious code from an infected plug-in. To mitigate these risks, Gradle provides dependency validation. Dependency validation verifies checksums and the signatures of dependencies and plug-ins used during build.

If dependency validation is enabled, Gradle will:

  • Ensure that dependencies are not tampered with (by validating their checksums)
  • Ensure the provenance of the dependencies and plug-ins you use (by verifying their signatures)
  • This reduces the risk of sending malicious code to production.

For more details and use of dependency validation, see: Verifying Dependencies

Declare proprietary repository dependencies

Gradle allows you to declare which repositories should be searched for specific dependencies. Gradle also allows you to declare proprietary dependencies that can only be found in one repository and should not be searched in any other repository.

For details on repository proprietary dependencies, see the User Manual

validationGradle WrappersThe integrity of the

Gradle WrapperIs a binary file of executable code in millionsGitHubUsed in the repository. If this file is changed, there may be some security risks

We created an officialGitHub ActionThat allows theGitHubIs automatically validated in its repositorygradle-wrapper.jarWhether theGradleRelease.

Of course, you can manually verify the validity of the Gradle Wrapper file by following the steps in the User Manual

Dependency management

Dependent parsing consistency

Configurations are resolved independently of dependencies. This can lead to a problem where the runtime classpath of the test may use a different version than the runtime classpath of the production code.

Gradle alleviates this problem by allowing you to declare consistency between dependency configurations in order to ensure that the versions of the common dependencies of the two classpath are consistent.

Repository unified declaration

Gradle (settings.gradle (.kts)); we can now easily define the repository for the entire build in settings.gradle (.kts) :

dependencyResolutionManagement {
    repositories {
        mavenCentral ()
    }
}
Copy the code

This allows Gradle to ensure that you use the same repository to resolve dependencies in all projects you build. To learn more, see How do I declare a repository for an entire build

Unified declaration of component metadata rules

Each module extracted from the repository has metadata associated with it, such as its group, name, version, and the different variants it provides, along with their artifacts and dependencies. Sometimes metadata is incomplete or incorrect. To manipulate this incomplete metadata in build scripts, Gradle provides an API to write component metadata rules. These rules take effect after the module’s metadata is downloaded and before it is used for dependency resolution.

dependencyResolutionManagement {
    components {
        withModule ('com.google.guava: guava', GuavaRule)
    }
}
Copy the code

For details on uniform declaration of component metadata rules, see Fixing Metadata with Component Metadata Rules

New features that rely on unified management

There are several ways to share dependent versions between projects in a multi-project build. For example, a user can declare the version or dependency coordinates directly in the ext block of the build script, in external files (such as dependencies. Gradle), buildSrc, or even in specialized plug-ins. However, there is no standard mechanism for combining the best of each approach to do this.

Gradle introduces the Version Catalog, which enables builders to centralize the dependency coordinates (groups, artifacts, versions) of their third-party dependencies in a regular configuration file and declare the actual dependencies in a type-safe manner.

Gradle7.0 is a new way to rely on unified management for Version Catalog

Type-safeProjectaccessor

GradleIs type safeProjectAccessors provide an experimental feature that can be found inIDEThe completion code in the autocomplete declaration to othersProjectThe dependence of



This relatively solves the pain point of adding dependency before us, but at present it seems only rightktsFor more details, see:Type-safe project dependencies

How to upgrade

Upgrade your build from Gradle 6.x to the latest