Hi all,
Gentle bump on this, with a status update.
Since my note on the 18th, *Gradle 9.6.0* was released, so I've targeted
that
(the current stable release) on my local branch — Gradle 9.6.0 on the Java
21 baseline, building and passing `./gradlew check` plus the per-module
test suites. (For reference, Lucene main is also on 9.6.0, so this keeps
the two projects aligned.)
A couple of concrete findings from doing the work, in case they help
the decision:
- The migration itself is the usual 8 -> 9 mechanical churn (the base {
archivesName } / java { } accessor moves, Project.exec -> injected
ExecOperations, the file-permissions and configuration-resolution API
changes, a couple of Groovy 4 fixes). Nothing surprising; Lucene's 9.x PRs
were a good template.
- The one real decision is still ca.cutterslade.analyze: it has no
Gradle-9-compatible release and fails every module, so something has to
give.
My branch currently drops it (matching Lucene main, which carries no
dependency-analysis plugin). I also have a working proof-of-concept
migrating to the autonomousapps Dependency Analysis plugin if the project
would rather keep dependency analysis — happy to share that separately, but
I'd suggest it not block the build-tool upgrade.
If there's no objection, I'll file a JIRA and open a focused PR for just
the Gradle 9.6.0 upgrade, and raise the dependency-analysis question on its
own. And if someone's already working on the Gradle 9 move, please say so
and I'll step
aside / help.Thanks, Serhiy Bzhezytskyy On Thu, 18 Jun 2026 at 17:25, Serhiy Bzhezytskyy <[email protected]> wrote: > 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 >
