Update Gradle to 9.6.1 - #22639
Conversation
9.4.1 was set in April; 9.5.0 and 9.6.x have shipped since. The wrapper bump itself is
two lines, but this repository sets
# Enforce the build to fail on deprecated gradle api usage
systemProp.org.gradle.warning.mode=fail
so every deprecation 9.6 introduces has to be resolved for the build to run at all.
Measured on main: zero Gradle deprecations on 9.4.1, 22 on 9.6.1. Each is also scheduled
to become an error in Gradle 10, so this clears that path too.
Implicit lookup of a parent project's methods and properties (13 sites):
- distribution/docker: taskName(...) called from the -export subprojects, now this.taskName
- distribution: a bare `libs` in the subprojects block resolved the parent's version-catalog
accessor, which also collides with the `libs` configuration declared right above it; the
catalog is now resolved explicitly, as StandaloneRestTestPlugin does, off rootProject --
:distribution has no VersionCatalogsExtension of its own. The bcFips configuration
resolves to an identical set of artifacts before and after.
- buildSrc: `allprojects { java { ... } }` reached into :build-tools:reaper, which applies the
java plugin and sets the same compatibility in its own script; the allprojects wrapper is
dropped. Both projects still compile to class file version 65 (Java 21).
- distribution/docker/docker-build-context: dockerBuildContext(...) is a closure on the
parent's ext, now parent.ext.dockerBuildContext.call(...)
- build.gradle: upstreamProject.base.archivesName, see below
Passing a Project as a dependency notation (6 sites): JarHellPrecommitPlugin,
ThirdPartyAuditPrecommitPlugin, LoggerUsagePrecommitPlugin, RestTestUtil, PluginBuildPlugin,
StandaloneRestTestPlugin -- all now DependencyHandler.project(String). Also the two
testReportAggregation / jacocoAggregation loops in build.gradle.
Project.getProperties (2 sites): qa/os/windows-2016 and windows-2012r2, now findProperty.
MavenArtifactRepository.getArtifactUrls: the whole feature is deprecated with no replacement,
and nothing in this repository ever sets artifactUrls, so RepositoriesSetupPlugin was
validating an always-empty collection. Removed.
Cross-project extra properties: repository-hdfs read krb5Conf/krb5Keytabs off the
krb5kdc-fixture project's ext at configuration time, which 9.6 no longer allows. The paths are
fully determined by the fixture's layout (testfixtures_shared, which is what TestFixturesPlugin
sets testFixturesDir to), so they are built locally instead.
The javadoc-linking fix also corrects a defect. That code read upstreamProject.base.archivesName
before the upstream project had been evaluated, so its base extension did not exist yet and the
implicit lookup silently returned the *parent's* name: :modules:autotagging-commons:common and
:spi were both linked as "rule-framework" while they publish common-*.jar and
autotagging-commons-spi-*.jar. Calling evaluationDependsOn first -- which the neighbouring
shadowed branch already does -- yields the published names.
precommit and assemble are green on 9.6.1 with zero deprecation warnings.
:distribution:docker:buildArm64DockerImage fails here for an unrelated reason -- the docker
build fetches tini from github.com inside the container and this network blocks it -- and it
fails the same way on unmodified main.
Signed-off-by: serhiy-bzhezytskyy <me@serhiy-bzhezytskyy.com>
PR Code Analyzer ❗AI-powered 'Code-Diff-Analyzer' found issues on commit bfd9f4a. ⛔ Hard block: Issues at Medium severity or above will block this PR from merging.
The table above displays the top 10 most important findings. Pull Requests Author(s): Please update your Pull Request according to the report above. Repository Maintainer(s): You can Thanks. |
The Code-Diff-Analyzer flagged the removal as silently weakening a security invariant, which is fair -- the reason was only in the PR text, not in the file. Reading getArtifactUrls() warns from DefaultMavenArtifactRepository#nagAboutArtifactUrlsDeprecation, and this build turns Gradle deprecations into failures via org.gradle.warning.mode=fail, so the call cannot stay. There is no non-deprecated way to read it either: the whole feature -- separate locations for POMs and artifacts, with no Maven equivalent -- is deprecated. @SuppressWarnings does not help, since this is a runtime nag rather than a javac warning. Nothing is lost in practice: artifactUrls' setters are deprecated too, no repository in this build sets them, and a build that did would already be failing on the setter. Signed-off-by: serhiy-bzhezytskyy <me@serhiy-bzhezytskyy.com>
|
Both
The two high findings are the wrapper JAR and the distribution URL/SHA256, which change on every bump by construction. Both were produced by |
sandeshkr419
added
skip-diff-analyzer
|
❌ Gradle check result for 92b5a7d: FAILURE Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change? |
2 participants
Description
Resolves #22638.
9.4.1 was set in April by #21153; 9.5.0 and 9.6.x have shipped since. The wrapper bump is two lines, but this repository sets
so every deprecation 9.6 introduces has to be resolved for the build to run at all. Measured on
main: zero Gradle deprecations on 9.4.1, 22 on 9.6.1. Each is also scheduled to become an error in Gradle 10.Implicit lookup of a parent project's methods and properties — 13 sites:
distribution/dockertaskName(...)called from the-exportsubprojects →this.taskNamedistributionlibsresolved the parent's version-catalog accessor, which also collides with thelibsconfiguration declared right above it. Now resolved explicitly asStandaloneRestTestPlugindoes, offrootProject—:distributionhas noVersionCatalogsExtensionof its own.bcFipsresolves to an identical set of artifacts before and after.buildSrcallprojects { java { ... } }reached into:build-tools:reaper, which applies the java plugin and sets the same compatibility in its own script. Wrapper dropped; both projects still compile to class file version 65 (Java 21).distribution/docker/docker-build-contextdockerBuildContext(...)is a closure on the parent'sext→parent.ext.dockerBuildContext.call(...)build.gradleupstreamProject.base.archivesName— see belowPassing a
Projectas a dependency notation — 6 sites (JarHellPrecommitPlugin,ThirdPartyAuditPrecommitPlugin,LoggerUsagePrecommitPlugin,RestTestUtil,PluginBuildPlugin,StandaloneRestTestPlugin) →DependencyHandler.project(String), plus the two aggregation loops inbuild.gradle.Project.getProperties—qa/os/windows-2016,windows-2012r2→findProperty.MavenArtifactRepository.getArtifactUrls— deprecated with no replacement, and nothing here ever setsartifactUrls, soRepositoriesSetupPluginwas validating an always-empty collection. Removed.Cross-project extra properties —
repository-hdfsreadkrb5Conf/krb5Keytabsoff thekrb5kdc-fixtureproject'sextat configuration time, which 9.6 no longer allows. The paths are fully determined by the fixture's layout, so they are built locally.One fix corrects a defect
The javadoc-linking code read
upstreamProject.base.archivesNamebefore the upstream project had been evaluated, so itsbaseextension did not exist yet and the implicit lookup silently returned the parent's name::modules:autotagging-commons:commonand:spiwere both linked asrule-framework, while they publishcommon-*.jarandautotagging-commons-spi-*.jar. CallingevaluationDependsOnfirst — which the neighbouringshadowedbranch already does — yields the published names.Testing
precommitandassemblegreen on 9.6.1 with zero deprecation warnings.:distribution:docker:buildArm64DockerImagefails in my environment because the Docker build fetchestinifrom github.com inside the container and my network blocks it — it fails the same way on unmodifiedmain.Check List
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.