Skip to content

SOLR-18289: Upgrade Gradle build to 9.6.0#4539

Open
serhiy-bzhezytskyy wants to merge 3 commits into
apache:mainfrom
serhiy-bzhezytskyy:gradle-9-upgrade
Open

SOLR-18289: Upgrade Gradle build to 9.6.0#4539
serhiy-bzhezytskyy wants to merge 3 commits into
apache:mainfrom
serhiy-bzhezytskyy:gradle-9-upgrade

Conversation

@serhiy-bzhezytskyy

Copy link
Copy Markdown

https://issues.apache.org/jira/browse/SOLR-18289

Description

Upgrades Solr's build from Gradle 8.10 to 9.6.0 (the current stable Gradle release). Solr is currently a full major version behind; this brings the build onto Gradle 9.x. The Java baseline is unchanged (Java 21) — this is purely a build-tool upgrade.

For reference, Lucene already completed the same 8 -> 9 migration and is on 9.6.0, so the migration path is well-trodden. (As discussed on the dev@ thread, Solr's build is independent of Lucene's; the one place version alignment helps is the lucene-dev composite build, which uses includeBuild against a local Lucene checkout.)

Changes

Gradle 8 -> 9 API migrations:

  • Wrapper + version catalog -> 9.6.0.
  • archivesBaseName -> base { archivesName }; sourceCompatibility / targetCompatibility moved under the java { } extension.
  • Project.exec / Project.javaexec are removed in Gradle 9 -> inject ExecOperations (the quietExec helper, ChangesToHtmlTask, CheckBrokenLinksTask, JavaCCTask).
  • ProjectDependency.dependencyProject -> dep / project(dep.path).
  • Archive/copy file modes -> dirPermissions / filePermissions / permissions { unix(...) }.
  • RAT classpath resolved at configuration time (Gradle 9 forbids resolving configurations at execution time).
  • jar-checks: drop the now-forbidden setCanBeConsumed(true) on a copied resolvable configuration.
  • render-javadoc: findRenderTasksInDependencies() made non-private (Groovy 4 dispatch on decorated task instances).
  • rat-sources: explicit import groovy.xml.XmlParser (Groovy 4).
  • webapp: webAppDirName -> from("web").

Other:

  • Dependency analysis: the ca.cutterslade.analyze plugin has no Gradle-9-compatible release; with Gradle dependency locking enabled (which Solr uses) it produces false-positive "unused dependency" failures across modules — see gradle-dependency-analyze#810. So this PR removes it — matching Lucene main, which carries no dependency-analysis plugin. Per the dev@ thread, adopting a Gradle-9-native replacement (e.g. the autonomousapps Dependency Analysis Gradle Plugin) is left as a separate follow-up so it doesn't block the build-tool upgrade.
  • netty-tcnative: the catalog pinned netty = 4.2.15 but netty-tcnative = 2.0.75; the netty BOM forces 2.0.77 in one module, so two versions resolved. Aligned the pin to 2.0.77 and updated the license checksum files.
  • The wrapper-bootstrap JDK upper bound is raised 23 -> 25 in a separate commit so it can be dropped easily if considered out of scope.

Lockfiles regenerated on Java 21.

Testing

Verified on Eclipse Temurin 21:

  • ./gradlew check (compile + all lint/validation: RAT, jar-checks, forbidden-apis, spotless, javadoc, broken-links, ecj) passes.
  • Per-module test suites pass. The full parallel ./gradlew test is intermittently flaky on a developer machine independent of this change (e.g. SolrProcessManagerTest spawns child JVMs and binds ports — a TOCTOU race; CollectionsAPISolrJTest ZK-watcher timing); the same failures reproduce on an unmodified main checkout and pass on rerun / in isolation.

AI assistance disclosure

Per Solr's AGENTS.md / how-to-contribute guidance: this change was prepared with the assistance of an AI coding agent and has been reviewed by me for correctness, scope, and alignment with Solr's build conventions.

Migrate Solr's build from Gradle 8.10 to 9.6.0, matching the version
already used by Lucene main. Java baseline stays at 21; this is purely a
build-tool upgrade.

Gradle 8 -> 9 API migrations:
- Wrapper and version catalog bumped to 9.6.0.
- archivesBaseName -> base { archivesName }; sourceCompatibility/
  targetCompatibility moved under the java { } extension.
- Project.exec/javaexec are removed in Gradle 9: inject ExecOperations
  into the quietExec helper (globals.gradle), ChangesToHtmlTask,
  CheckBrokenLinksTask and JavaCCTask.
- ProjectDependency.dependencyProject -> dep / project(dep.path).
- Archive/copy file modes -> dirPermissions/filePermissions/permissions
  { unix(...) }.
- RAT: resolve the rat classpath at configuration time (Gradle 9 forbids
  resolving configurations at execution time).
- jar-checks: drop the now-forbidden setCanBeConsumed(true) on a copied
  resolvable configuration.
- render-javadoc: make findRenderTasksInDependencies() non-private so the
  decorated task instance can call it under Groovy 4.
- rat-sources: explicit import of groovy.xml.XmlParser (Groovy 4).
- webapp: webAppDirName -> from("web").

Remove ca.cutterslade.analyze dependency analysis:
- The plugin is incompatible with Gradle 9 (no released version supports
  it; see gradle-dependency-analyze issue apache#810, false positives under
  dependency locking) and fails every module. Lucene main carries no
  dependency-analysis plugin, so drop it here too rather than block the
  upgrade. Removes dependency-analyze.gradle and the per-module
  permitUnusedDeclared / permitTestUnusedDeclared declarations.

Lockfiles regenerated on JDK 21.
Gradle 9.5.1 supports running on newer JDKs, so raise the upper bound in
the wrapper bootstrap's version check from 23 to 25. Not required to build
on the Java 21 baseline; split out so it can be dropped independently if
out of scope.
The version catalog pinned netty = 4.2.15.Final but netty-tcnative =
2.0.75.Final. The netty 4.2.15 BOM (pulled into :solr:modules:opentelemetry
via grpc-netty) forces tcnative to 2.0.77.Final there, while other modules
resolved the catalog-pinned 2.0.75 — so two tcnative versions resolved
across the build. Under Gradle 9 this surfaced as a checkDanglingLicenseFiles
warning (the 2.0.77 license files are required by opentelemetry's
validateJarChecksums but not collected by the dangling-file check).

Align the catalog pin to 2.0.77.Final so the whole build resolves a single
version; swap the 2.0.75 license checksum files for 2.0.77 ones and
regenerate lockfiles.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant