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 of
Java 16
The development of - use
included builds
Simplify the build - Reduced through new dependency management features
Multi-Project
The maintenance cost of the build - Use the latest version
Groovy
andKotlin
The development of
Performance optimization
fasterup-to-date
check
Fast feedback from local incremental compilation is critical to improving development efficiency. File system monitoring determines which files have changed by reducing themIO
Operation to improve incremental compilation speed
As ofGradle 7.0
, including the most recent versionWindows
.Linux
andMacOS
This 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 DSL
Script 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 cache
shooting
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 cache
More work is done in parallel, and construction can be acceleratedexecution
Phase.
Please note that this feature is currently experimental, not enabled by default, and sinceGradle 7.0
Not 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.
- each
Gradle
Instances can all access the shared read-only dependency cache, which avoids redundant downloads between builds. - Can be found in
Gradle
This cache is securely shared between instances without creating separate copies of it.
Ease of use and new feature optimization
JVM
Toolchain 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
Gradle
Will check localJava
If no one locally matches the build requirementsJava
Version,Gradle
Will be taken fromAdoptOpenJDK
The 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 builds
In 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 Wrappers
The integrity of the
Gradle Wrapper
Is a binary file of executable code in millionsGitHub
Used in the repository. If this file is changed, there may be some security risks
We created an officialGitHub Action
That allows theGitHub
Is automatically validated in its repositorygradle-wrapper.jar
Whether theGradle
Release.
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-safeProject
accessor
Gradle
Is type safeProject
Accessors provide an experimental feature that can be found inIDE
The completion code in the autocomplete declaration to othersProject
The dependence of
This relatively solves the pain point of adding dependency before us, but at present it seems only rightkts
For more details, see:Type-safe project dependencies
How to upgrade
Upgrade your build from Gradle 6.x to the latest