+1 to do a jira and PR on the gradle upgrade only, without the dep.analyze plugin, which can be tackled as a follow up.
Jan Høydahl > 20. juni 2026 kl. 07:42 skrev Serhiy Bzhezytskyy > <[email protected]>: > > 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 >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
