Thanks you for looking into this. I have no experience with that specific Gradle plugin; I'm looking forward to seeing what it looks like. Maybe you could simply throw up a draft PR of your WIP for consideration? Keeping a Kotlin version in sync sounds simple to me. I'm not keen on upgrading some depdendency scopes from "implementation" to "api" by the strict analysis of a tool that is very likely to be "api"-happy for the most trivial of API exposure. In my experience managing dependencies, liberal use of "api" is a big mistake as it's viral/transitive to the recipient. Before long, everything depends on everything for the most flimsy/trivial of reasons at each linkage. So I think it takes human judgement on a case-by-case basis. I'm not saying the current choices is perfection.
On Fri, Jul 3, 2026 at 3:45 AM Serhiy Bzhezytskyy <[email protected]> wrote: > Hi all, > > Following up on the dependency-analysis question I flagged during the > Gradle 9 upgrade (SOLR-18289). > Recap: ca.cutterslade.analyze is incompatible with Gradle 9, so that PR > dropped it, matching Lucene main (which carries no dependency-analysis > plugin at all). > > I have a working migration to the Dependency Analysis Gradle Plugin > (com.autonomousapps "build-health") on a branch rebased on current main: > buildHealth passes with zero violations after applying its advice > (implementation -> api where deps are exposed in the public ABI, plus > removal of genuinely-unused declarations) — about 110 > dependency-declaration changes across 26 modules, mechanical but not small. > Per-project suppressions are documented (notably :solr:ui, Compose/KMP). > > One caveat worth surfacing: the plugin needs its bundled kotlin-metadata > version kept in sync with Solr's Kotlin — its current release can't parse > Kotlin 2.4.0 metadata and crashes on :solr:ui until forced to match. It > works, but it's ongoing maintenance against a fast-moving module. > > So this is a policy question, not a feasibility one: does Solr want > dependency analysis back in the build, or stay plugin-free like Lucene? > If there's appetite I'll create a JIRA and open the PR; if the consensus is > plugin-free, that's less to maintain and I'll happily drop it. > > Thanks, > Serhiy > > On Sun, 21 Jun 2026 at 08:23, Serhiy Bzhezytskyy < > [email protected]> > wrote: > > > PR is up: https://github.com/apache/solr/pull/4539 — CI is waiting on a > > maintainer to approve the workflows (first-time contributor). Thanks > again > > for the quick JIRA, and for the warm welcome! > > > > > > On Sun, 21 Jun 2026 at 07:27, David Smiley <[email protected]> wrote: > > > >> https://issues.apache.org/jira/browse/SOLR-18289 > >> > > >
