serhiy-bzhezytskyy opened a new pull request, #4539:
URL: https://github.com/apache/solr/pull/4539

   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](https://github.com/gradle-dependency-analyze/gradle-dependency-analyze/issues/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.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to