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