Gradle 8.11

What's new in this version:

New features and usability improvements:
Configuration Cache improvements:
- Gradle's Configuration Cache improves build performance by caching the result of the configuration phase. Gradle uses the Configuration Cache to skip the configuration phase entirely when nothing that affects the build configuration has changed.

Faster Configuration Cache with parallel load and store:
- When enabled, the Configuration Cache can greatly increase build performance. However, for large and complex builds, storing and loading cache entries can still incur a noticeable overhead.
- To address this, storing and loading of the Configuration Cache can now be performed in parallel, resulting in better performance in case of both cache misses and hits.
- To enable the feature, add the following flag in gradle.properties:
- org.gradle.configuration-cache.parallel=true
- This is an incubating feature and may expose concurrency issues in some builds
- For more details on configuring parallel caching, see Configuration Cache

Configuration Cache enabled by default when using the Build Init plugin:
- The Configuration Cache has been stable since Gradle 8.1 and is already widely used. As we work towards making it the preferred mode of execution, we continue to encourage further adoption.
- Starting with this release, projects generated by the Build Init plugin enable the Configuration Cache via the root gradle.properties file. This also includes projects converted from Maven.

Configuration Cache compatibility for C++ and Swift plugins:
- Most core plugins and Gradle features are already compatible with Configuration Cache. This release also addresses the compatibility of native plugins.

The following C++ and Swift plugins are now Configuration Cache compatible:
- Swift application
- Swift library
- XCTest
- C++ application
- C++ library
- CppUnit
- GoogleTest
- Visual Studio
- XCode

Error and warning reporting improvements:
- Gradle provides a rich set of error and warning messages to help you understand and resolve problems in your build
- The new Problems API is getting integrated across more Gradle core components, providing more structured and consistent error reporting, helping to make error reporting cleaner and more actionable

Improved Java compilation task failure reporting:
- In previous Gradle versions, finding the reason for a failed Java compilation was not always easy. In case of long build output, users typically had to scroll back and manually locate the failed task's output where the compiler error details could be found. Using the --continue flag further complicated discovery, making it challenging to identify the exact failure.
- In this release, Java compilation warning and errors are summarized during task execution and at the end of the build log.
- Note that the current solution reports upon Java compilation failures. If only warnings occur (and no -Werror is set), they will not be repeated at the end of the build.
- This feature also works with the --continue flag, and the bottom report will contain a per-task message of all the compilation failures.

Consolidated report for warnings and deprecations:
- Deprecation and other warnings are now presented in a rich report generated at the end of the build. This report serves as a central location for users to review problems that occurred during a build.
- Plugin authors can use the Problems API to log events specific to their plugins, adding to the Gradle-generated ones
- The report is always generated, even if no issues have been reported. If you do not want to generate this report, you can disable it with the --no-problems-report flag.

Build authoring improvements:
- Gradle provides rich APIs for plugin authors and build engineers to develop custom build logic

Root variant exposed by the Resolution Result API:
- The ResolutionResult API, which contains the results of dependency resolution, now exposes the root variant of the resolved graph in addition to its owning component

Previously, the API only exposed the root component, which exposed the first-level dependencies as well as dependencies from other selected variants in the root component:
- val rootComponent = configurations.runtimeClasspath.incoming
- .resolutionResult.rootComponent

In this release, the root variant is also exposed. The root variant is a synthetic variant representing the Configuration being resolved, and exposes the first-level dependencies of a resolution:
- val rootVariant = configurations.runtimeClasspath.incoming
- .resolutionResult.rootVariant
- The updated API allows for more precise traversal of dependency graphs by operating at the variant level instead of the component level. For example, traversing dependencies at the variant level allows users to differentiate between a component's production code and its test fixtures.
- For more details on how to perform a graph traversal, see Programmatic Dependency Resolution

API for selecting variants by feature name:
- Using the requireCapability API, Gradle allows variants of a target component to be selected based on the group and name of the variant's capability. This functionality is used to select "features" of a target component, such as a library's test fixtures. However, this API can be difficult to use when targeting a project dependency, as the group and name of the target project are not known when declaring a project dependency.

Gradle 8.11 introduces a new requireFeature API that is specifically tailored for selecting variants of a target component using the feature name. Selecting a capability by feature name is equivalent to requesting a capability with the following form: ${project.group}:${project.name}-${featureName}

Introduced project path accessor on ProjectDependency:
- This release introduces ProjectDependency#getPath() for accessing the identity of the target of a project dependency

Native toolchains support:
- Gradle's native toolchain support enables building C/C++ projects with compilers like GCC, Clang, and Visual C++

Linux arm64 as a build target:
- This release adds Clang and GCC support to Gradle on Linux platforms that use the ARM or AArch64 architecture

Promoted features:
- Promoted features are features that were incubating in previous versions of Gradle but are now supported and subject to backward compatibility. See the User Manual section on the “Feature Lifecycle” for more information.
- The following are the features that have been promoted in this Gradle release

Stable Build Features API:
- The BuildFeatures API is now stable. It allows users to check the status of Gradle features such as configurationCache and isolatedProjects

Stable methods in ProviderFactory API:
The following methods of the ProviderFactory are now stable:
- exec
- javaexec
- environmentVariablesPrefixedBy(String)
- environmentVariablesPrefixedBy(Provider)
- gradlePropertiesPrefixedBy(String)
- gradlePropertiesPrefixedBy(Provider)
- systemPropertiesPrefixedBy(String)
- systemPropertiesPrefixedBy(Provider)
- The ExecOutput and ExecOutput.StandardStreamContent interfaces are now stable too.

Fixed:
- 101 issues have been fixed in Gradle 8.11
- init.d whoups again
- Gradle Tutorial Wrong Code
- Incorrect CC entry size reported in build operation
- Duplicate text
- Upgrade Wrapper
- Add release notes entry for requireFeature
- Move generating dependency-accessors to Global cache
- Unformatted Markdown link in 'Working With Files'
- Build service parameters being duplicated across all projects
- Parameter order incorrect in "Running Tasks" tutorial page - Step 2
- Documentation defaults to Groovy code snippets in incognito mode
- Remove lenient class encoding behavior
- initscript init.d documentation
- Configuration cache failure for lambda `DefaultScriptCompilationHandler$1`
- "multi-project build that contains two subproject" shows example with 3 subprojects?
- ProblemSpec.withException() should accept Throwable
- Remove `plugin()` method from `ProblemSpec`
- Remove inconsistency between Problems.throwing and Problems.rethrowing
- Remove namespace concept from Problems API
- Java compilation ids should be more refined in problems API reports
- Deprecating project.exec and project.javaexec
- Relocated artifact having a version set to "${project.version}" can't be downloaded from maven central
- Cache-cleanup retention is incorrect when used with configuration-cache
- Don't report lenient resolution failures to Problems API
- Parallel CC store should be an opt-in
- Java compilation errors are missing from build scans failure page
- Provide a flag to disable parallel configuration for IP mode in favor of configure-on-demand
- Improve Javadoc of ConfigurableFilePermissions.html#unix(int)
- Failure during configuration when applying a plugin causes configuration-cache report to be written to the default build directory
- Parallel configuration configures projects that should be excluded by Configuration On Demand
- Gradle generates Kotlin DSL accessors for Configurations with invalid identifiers
- Deprecate `Javadoc.isVerbose/setVerbose` and prefer verbose setting on `CoreJavadocOptions`
- Java API extraction ignores annotation default values
- Local build cache configuration shown in build scans does not match actual configuration
- RC Changelogs appear on Google Search instead of final releases
- Links in Logging docs not converted from Markdown to HTML
- Flip a way `isolatedProjects` test executor being enabled for subprojects
- Force parallel project configuration before model building
- Enable `isolatedProjects` tests in `:plugins-java-library`
- Support `@ToBeFixedForXXX` interceptors for tests that have `enableProblemsApiCheck`
- Finalizer task input can be destroyed with Configuration Cache enabled
- Problem summary page cannot be opened if a reported problem contains multiple solutions
- Problem summary file should be in buildDir/reports directory
- Gradle should always generate a problem summary report
- Test Fixtures are incompatible with project isolation
- Deprecate setters for Nested JavaBean properties identified during migration
- Wrong command output
- Validate parallel configuration with Isolated Projects
- Deprecate Dependency.contentEquals
- Support parallel sync test scenario in `smoke-ide-tests`
- Inconsistent text / snippet in the "Implementing Custom Tasks"
- Task to update Gradle daemon JVM toolchain should use JavaLanguageVersion and not JavaVersion
- Show Java compiler errors at the end of the build
- PropertyUpgradeAnnotatedMethodReader sometimes visits annotation on class outside of a project
- In Gradle 8.9 the configuration for Jacoco Coverage Report Aggregation no longer works
- Missing Groovy DSL snippets in Writing Build Scripts chapter
- Test report aggregation plugin fails when configuration cache is enabled.
- Improve boolean property upgrade accepted binary compatibility changes
- Gradle header dependencies is sensitive to the source ordering
- Replace constants in SourceFileHeader
- Javadoc styling clashes when Gradle's dark theme is enabled
- Fix upgrading properties with getters in `core-api`
- Gradle module metadata spec implies non-relative URLs for files are valid, but they are not
- Poor performance of SourceDistributionProvider on the cold start
- Precompiled script plugin on Groovy with a package declaration
- Prototype custom console rendering for Java compiler problems
- Parallel dependency resolution for configuration cache
- Misleading gradle 9 deprecation warning when using JvmVendorSpec.IBM
- Promote Build Features API to stable
- Deprecate AbstractOptions#define and AbstractOptions
- [8.3] `Problems reading data from Binary store in ...`
- Document ArtifactView
- Provide a 'feature("featureName", "g:a")' dependency declaration syntax in the spirit of 'testFixtures("g:a")'
- Evaluate usages of Configuration#copy
- build init plugin should enable configuration cache for generated builds
- Clean up Gradle configuration caches periodically
- Task abbreviation behavior changes based on JDK used
- Groovy 4 Gradleception build runs OOM sometimes
- Deprecate ForkOptions.javaHome
- Deprecate SourceDirectorySet.getSrcDirTrees()
- Version range without upper bound with square brackets does not work
- Disallow usages locale-dependent toLowerCase() and toUpperCase() calls in the codebase
- Make `swift-application` plugin support the configuration cache
- Make `cpp-unit-test` plugin support the configuration cache
- Make `xctest` plugin support the configuration cache
- Make `swift-library` plugin support the configuration cache
- Make `cpp-library` plugin support the configuration cache
- Make `cpp-application` plugin support the configuration cache
- Make `visual-studio` plugin support the configuration cache
- Please mention how to view help for a specific task in 'usage' output
- Detached configurations cannot extend from existing configurations
- Fix `toLowerCase` sensitivity regarding `Locale`
- Gradle doesn't report abbreviated task name as ambiguous when task name has numbers
- Using Gradle 8.11 Project.exec/javaexec are deprecated, but ProviderFactory.exec/javaexec work differently.
- 8.11-rc-1 fails to build 'java-library' project on ARMv7
- REGRESSION: `ValueSource` instances are no longer shared across projects in 8.11-rc-1
- Introduce ProjectDependency#getPath
- Hang downloading dependencies during IntelliJ sync in Gradle 8.11-rc-1
- Deadlock with configuration cache in Gradle 8.10
- Java compilation failures in problem report html are unintelligible
- It's not possible to report problems to the Tooling API from a Worker API task