+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] > >
