Thanks Jan, David — that's the plan, then: a focused JIRA + PR for the Gradle 9.6.0 upgrade only, dropping the cutterslade plugin, with dependency analysis (DAGP or otherwise) as a separate follow-up.
David — yes please, if you wouldn't mind creating the JIRA, that'd be a big help; I don't have an ASF JIRA account yet. Once it's filed I'll link the PR to it. (Happy to apply for an account too if that's preferable long-term — just let me know.) On your Lucene question — you're right, and I overstated the "match Lucene" angle. Solr's build is independent, so what Lucene runs doesn't matter for the upgrade itself; the real reasons are simply that 8.10 is two majors behind the current stable Gradle (9.6.0) and that newer JDK/toolchain support lives in 9.x. I should have led with that. The one place it genuinely does matter is exactly the case you flagged: *gradle/lucene-dev/lucene-dev-repo-composite.gradle* uses *includeBuild* to build Solr against a local Lucene checkout (*-Plucene.dev.path*=...), and *includeBuild* across two builds wants compatible Gradle versions — so for anyone doing local Lucene+Solr co-development, keeping the two within the same Gradle major avoids friction there.(it was my case) That's the real (and narrow) reason, not a general "follow Lucene" rule. I'll watch for the JIRA and open the PR. Thanks both for the quick reads. Best regards, Serhiy On Sat, 20 Jun 2026 at 23:59, David Smiley <[email protected]> wrote: > +1 from me, repeating what Jan said. I think he means drop the > "cutterslade" plugin, as there is no "dep.analyze". And I took a quick > look and see no existing JIRA. If you'd like, I can create the issue > (perhaps you don't have an account and don't want to bother). > > Thanks for tackling this!! > > BTW I don't think what Lucene's build is doing matters that much... am I > missing something? The only way I can think it matters is if you want to > enable the Gradle includeBuild feature, which might require some degree of > Gradle version alignment. > > On Sat, Jun 20, 2026 at 3:56 PM Jan Høydahl <[email protected]> wrote: > > > +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] > > > > >
