Hi all,
Lucene main has been on Gradle 9.x for a while now, but Solr main is still
on Gradle 8.10. With Lucene moving to a Java 25 baseline, Solr will need to
be on Gradle 9 before long, so I took a run at the upgrade locally and have
it building and passing "checks" on Java 21.
I'd like to contribute it, and before opening anything I want to check
nobody is already on this, and get direction on one decision the upgrade
forces.
*The Gradle 9 upgrade*
Mechanically it's the usual 8 -> 9 migration: wrapper bump to 9.5.1, the *base
{ archivesName } / java { sourceCompatibility } *accessor moves, *Project.exec
-> injected ExecOperations* in a few tasks, the file-permissions API (
*dirPermissions/filePermissions*), the RAT and jar-checks config-resolution
rules, Groovy 4's `XmlParser` import, etc. Java baseline stays at 21 — this
is purely the build-tool upgrade. ~24 source files plus regenerated
lockfiles. I leaned on Lucene's own Gradle 9.x PRs as precedent.
I'm happy to open this as a focused PR.
*The decision: ca.cutterslade.analyze is dead on Gradle 9*
The one thing the upgrade can't sidestep is the
*ca.cutterslade.analyze *dependency-analysis
plugin. It is incompatible with Gradle 9 (no released version supports it;
it fails every module — cf. its issue #810 re: false positives under
dependency locking). Bumping it to its latest (2.0.0) does not help.
So you/we have to decide what dependency analysis looks like on Gradle 9.
Three options as I see them:
1. Drop it entirely, as Lucene main did — Lucene carries no
dependency-analysis plugin at all, relying on dependency locking + OWASP +
forbidden-apis. Simplest; matches the sibling project.
2. Replace it with the actively-maintained Dependency Analysis Gradle
Plugin (com.autonomousapps, *"DAGP"*), which is Gradle-9 native.
3. Something else.
I've actually done (2) locally to see what it entails, so the choice can be
made with data rather than guesswork. DAGP runs cleanly across the whole
build and its findings are real — e.g. ~40 dependencies in *solr-core* are
exposed in public ABI and should be *api* rather than *implementation*
(verified
via its *reason *task), plus a handful of genuinely-unused test deps. It
needs a few documented suppressions: most notably *:solr:ui *(Kotlin
Multiplatform / Compose) where its JVM-bytecode analysis can't see
Compose-compiler-wired dependencies and produces false "unused" verdicts.
Applying all of its advice is a sizable, opinionated diff (~110
dependency-declaration changes across 26 modules) that widens the public
API surface in many modules.
My instinct: land the Gradle 9 upgrade first as its own change, and treat
dependency analysis as a separate decision/PR so the build-tool bump isn't
held up by a policy discussion. But if the consensus is "drop it like
Lucene," that's even less work and I'll go that way.
What's the appetite here, and is anyone already working on the Gradle 9
move?
Thanks,
Serhiy Bzhezytskyy
