Gradle 6.6

What's new in this version:

Performance improvements:
- Fast feedback for local incremental builds is crucial for developer productivity. This is especially true when your IDE uses Gradle to build and run tests for your project, which IntelliJ IDEA does by default. This scenario has been the primary focus of performance improvements since Gradle 6.5 and will continue for the next several Gradle releases.
- Configuration caching
- Before running any task, Gradle needs to run the configuration phase. Currently, this is done on every build invocation and can incur a noticeable overhead, especially in large projects.
- The configuration cache significantly improves build performance by caching the result of the configuration phase and reusing it for subsequent builds. Using the configuration cache, Gradle can skip the configuration phase entirely when nothing that affects the build configuration has changed as you can see below.
- Additionally, Gradle is able to optimize task execution when configuration caching is enabled and execute more tasks in parallel by default.
- Note that configuration caching is different from the build cache, which caches outputs produced by the build. The configuration cache captures only the state of the configuration phase.
- IDE sync and import does not currently benefit from configuration caching.
- This feature is considered highly experimental and not enabled by default or recommended for production use. Tasks and plugins usually require changes to meet the requirements to use configuration caching. Not all core Gradle plugins have been updated yet and some features are not yet implemented. Your build may likely require changes.
- You can enable this experimental feature by supplying the parameter --configuration-cache on the command-line or adding it to your run configuration. If your build is incompatible with configuration caching, Gradle will generate a report describing the problems found.
- Learn more about this new feature and its impact in the Configuration Cache documentation.
- Stability improvements of file-system watching
- Gradle 6.5 introduced an experimental opt-in that improves the performance of local incremental builds by watching for file-system changes.
- This release brings a number of stability improvements for file-system watching when used with composite builds or large projects on Windows and macOS. Gradle will now report better errors when you enable file-system watching on unsupported systems.
- Improved cache hits with normalized runtime classpaths
- For up-to-date checks and the build cache, Gradle needs to determine if two task input properties have the same value. In order to do so, Gradle first normalizes both inputs and then compares the result.
- Runtime classpath analysis now inspects manifest and META-INF properties files, ignoring changes to comments, whitespace and order-differences. Moreover, you can selectively ignore attributes or properties that don't impact the runtime classpath.
- normalization {
- runtimeClasspath {
- metaInf {
- ignoreAttribute("Implementation-Version")
- ignoreProperty("timestamp")
- This improves the likelihood of build cache hits when any ZIP file on the classpath is regenerated and only differs by unimportant values or comments. The most common case where this sort of normalization can be useful is with JAR files, but it can be applied to any ZIP file on the classpath--such as AAR, WAR, or APK files.
- See the user manual for further information. Note that this API is incubating and will likely change in future releases as support is expanded for normalizing properties files outside of the META-INF directory.

New features and usability improvements:
- Conventions for handling user-provided credentials
- Builds sometimes require users to supply credentials. For example, credentials might be required to authenticate with an artifact repository in order to publish an artifact. It's a good practice to keep credentials outside the build script.
- This release includes a new API for credentials that makes working with credentials easier by establishing a convention to supply credentials using Gradle properties that can be provided to the build as command-line arguments, environment variables, or as values in a gradle.properties file. It also introduces fail-fast behavior when Gradle knows that the build will need credentials at some point and the credentials are missing.
- Starting from this release, you can easily externalize credentials used for authentication to an artifact repository:
- repositories {
- maven {
- name = 'mySecureRepository'
- credentials(PasswordCredentials)
- // url = uri(<<some repository url>>)
- The credentials for mySecureRepository will be searched for in Gradle properties with the names mySecureRepositoryUsername and mySecureRepositoryPassword.
- For more details on using the new API to authenticate with artifact repositories, see the user manual section as well as an updated sample.
- You can also use the new provider API directly to supply credentials to an external tool:
- tasks.register('login', Exec) {
- def loginProvider =
- providers.credentials(PasswordCredentials, 'login')
- inputs.property('credentials', loginProvider)
- doFirst {
- PasswordCredentials loginCredentials = loginProvider.get()
- // use credentials
- The credentials for the above will be searched for in Gradle properties with the names loginUsername and loginPassword.
- See the updated sample for more details.
- Support for the --release flag in Java compilation
- Java 9 introduced cross compilation support with the --release flag on the Java compiler. This option tells the compiler to produce bytecode for an earlier version of Java and guarantees that the code does not use any APIs from later versions.
- In previous Gradle versions, it could be achieved through the use of compilerArgs and making sure that sourceCompatibility and targetCompatibility are not set:
- compileJava {
- options.compilerArgs.addAll(['--release', '7'])
- With this release, Gradle makes this use case easier by supporting the --release flag for Java compilation directly on the CompileOptions of JavaCompile tasks:
- compileJava {
- options.release = 7
- See the section on cross compilation for details.
- Dependency management improvements
- Reproducible Gradle Module Metadata
- Gradle Module Metadata is a format used to serialize the Gradle component model, similar to but more powerful than Maven’s POM.
- By default, the Gradle Module Metadata file contains a build identifier field which defaults to a unique ID generated during build execution. This behaviour can now be disabled at the publication level, allowing users to opt-in for a reproducible Gradle Module Metadata file. This enables downstream tasks to consider it up-to-date, resulting in faster and reproducible builds.
- main(MavenPublication) {
- from components.java
- withoutBuildIdentifier()
- See the documentation for more information on Gradle Module Metadata generation.
- Variant-aware dependency substitution rules
- It’s a common problem in dependency management that the same dependency can appear in a dependency graph but with different attributes. For example, you want to only use the “fat jar” with repackaged dependencies, but the regular jar is pulled in transitively. The far jar may be published under a "fat jar" classifier, while the regular jar has no classifier.
- Previously, it wasn't possible for Gradle to substitute a dependency using a classifier with a dependency without a classifier, nor was it possible to substitute a dependency without classifier with a dependency with a classifier.
- Similarly, other attributes (typically "platform" dependencies) or capabilities could not be used when describing dependency substitutions.
- Gradle now supports declaring substitutions based on classifiers, attributes, or capabilities. Gradle's dependency substitution API has been enriched to cover those cases.
- See the documentation on variant-aware substitution for details.
- Improvements for plugin authors:
- Injectable ArchiveOperations service
- Previously, it was only possible to create a FileTree for a ZIP or TAR archive by using the APIs provided by a Project.
- However, a Project object is not always available, for example in worker actions or when using the configuration cache.
- The new ArchiveOperations service has zipTree() and tarTree() methods for creating read-only FileTree instances respectively for ZIP and TAR archives.
- See the user manual for how to inject services and the ArchiveOperations API documentation for more details and examples.
- Combining two providers
- When using Lazy Properties, it’s common to compute a value by combining the values of two providers. In previous Gradle releases, it wasn’t possible to do this without eagerly reading one of the provider values or losing dependency information. Gradle 6.6 introduces a zip method which lets you provide the combined value lazily.:
- def hello = objects.property(String).convention("Hello")
- def world = objects.property(String).convention("World")
- def helloWorld = hello.zip(world) { left, right ->
- "${left}, ${right}!".toString()
- // ...
- hello.set("Bonjour")
- world.set("le monde")
- println(helloWorld.get()) // prints “Bonjour, le monde!”
- Refer to the API documentation for details.
- Security improvements:
- Removed debug logging of environment variables
- Debug level logging may expose sensitive information in the build log output, for example in CI server logs. For this reason, Gradle displays a prominent warning when using debug level logging since version 6.4. One example of this risk is leaking secret values such as credentials stored in environmental variables.
- Previously, when debug level was enabled, Gradle used to log all environment variables when starting a process such as a test, Gradle daemon, or when using Project.exec. In practice, this means most of the builds logged environment variables on debug level.
- As an additional security precaution, Gradle no longer logs environment variables when starting processes starting with this version.
- Note that many CI servers, like Jenkins and Teamcity, mask secrets in the captured logs. Still, we recommend limiting the usage of debug level logging to environments which do not capture the log output, like your local machine. Build scans never capture the debug log as part of the console log even when you enabled debug logging.
- As an additional measure, you may want to limit the environment variables passed to the test task or other forked processes by explicitly using ProcessForkOptions.setEnvironment(). This way the forked processes themselves cannot leak secrets from the environment, since they don't have them available anymore.

Fixed:
- Runtime classpath normalization should apply to zips and to nested zips in classes directories
- Stackoverflow visiting file collections referencing themselves
- System.getProperty(...) with null default value triggers NPE
- java.lang.RuntimeException: Problems reading data from Binary store
- Configuration cache should support dynamic and changing dependencies
- Configuration cache should support dependency locking
- Make `java-gradle-plugin` plugin support the configuration cache
- Make `ear` plugin support the configuration cache
- Make `war` plugin support the configuration cache
- Make `java-library-distribution` plugin support the configuration cache
- Make `distribution` plugin support the configuration cache
- Make `application` plugin support the configuration cache
- Make `java-platform` plugin support the configuration cache
- Make `java-library` plugin support the configuration cache
- Make `java` plugin support the configuration cache
- [6.6-milestone-1] Gradle wrapper task throws NumberFormatException with OpenJDK 15
- Exception stacktrace shown upon startup when file-system watching is enabled on certain older Linux distributions
- Missing classes with Scala incremental compilation
- Kotlin compiler daemon keeps disappearing with file-system watching enabled on macOS
- compileKotlin task has unstable task inputs with precompiled `.gradle.kts` scripts
- CL code snippets are broken in Gradle docs
- Make sure file system watching is enabled consistently during a build
- Make Project.zipTree() and Project.tarTree() available via injected services
- Configuration cache can fail when artifact transform is chained and takes artifact dependencies as a parameter
- Broken non-incremental compilation with Scala
- Watch root directories of included builds
- Artifact collection contains different results when loaded from configuration cache
- Rename "VFS retention" to "file-system watching" in public types and messages
- Investigate what files are watched outside of the root directory
- JVM crash with file-system watching enabled on Windows
- java14 helpful NPEs not working in test
- exclusiveContent API fails with "Cannot mutate content repository descriptor..."
- incorrect docs for how to disable scala incremental compilation
- Stop watching caches in Gradle user home and in the `$rootDir/.gradle` directory
- Allow GenerateModuleMetadata and GenerateMavenPom to be reproducible
- Make up-to-date checks for :kotlinCompilerEmbeddable:unpackPatchedKotlinCompilerEmbeddable faster
- Give user information about increasing inotify watch count when needed
- Configuration cache property serialization should consider custom writeObject/readObject methods
- Gradle 5.1.1 does not retry connection resets
- POM dependency with `<type>` bypasses variant-aware resolution, even when conflict-resolved with project dependency
- Dependency substitution is broken for those with <type> attributes in POM files
- Dependency substitution rules
- Add property for setting the `--release` compiler argument
- Buildscript dependencies have bad handling of pom files
- local projects dependencies no longer work in gradle 6.6-rc-1
- Java plugin can overwrite the classpath of Test tasks added by other plugins
- 6.6RC1: error message for missing credentials is duplicated
- Causes of custom AssertionErrors should be preserved
- ClassDirectories property of `JacocoReport` is annotated with @Classpath
- Instrumentation causes a duplicate method and a `ClassFormatError` at runtime
-Suppressed exceptions thrown by tests are not captured in the test report and build scan