Hi David, Thanks — I put the DAGP work up as code, split into three layers so each can be judged on its own rather than as one all-or-nothing diff. They stack:
#4612 (ready) — part 1/3: wire in the plugin (configured to REPORT, not fail — it's guidance, not enforcement) + the uncontroversial advice only: unused-dependency removals and a couple test-scope fixes. This is the one I'd actually like to merge; it closes the dependency-analysis item deferred from the Gradle 9 upgrade. #4613 (draft) — part 2/3: the ~36 inter-module project() api promotions, where 'api' is genuinely correct (e.g. solr-core publicly exposes solrj types). For review. #4614 (draft) — part 3/3, NOT for merge: the ~76 external-library api promotions DAGP wants, shown for discussion. I agree with your api-happiness point and don't recommend applying them — they'd leak transitively for often-trivial exposure. One is concrete evidence of the harm: DAGP wanted jersey-core-server as api, but that won't even resolve (its version comes from a BOM declared implementation), so I had to exclude it just to make the branch build. Suggested flow: merge #4612 if it looks good; then on #4614 point at any external deps you consider genuinely public and I'll fold just those into #4613, dropping the rest. Serhiy On Fri, 3 Jul 2026 at 23:19, David Smiley <[email protected]> wrote: > 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 > > >> > > > > > >
