After reviewing your PRs and doing my own investigation... I see that search.maven.org is less useful than I hoped. It didn't fully resolve the transitive graph, even though through the UX I asked it for transitives. In particular, for solr-opentelemetry, it could only traverse as far as grpc-netty without seeing the specific netty dependencies you were speaking of and that which we indeed ship in releases. So I'll continue to use it knowing that it isn't comprehensive. That's not good enough for the VEX analysis you are doing.
BTW when I spoke of Solr's TGZ, it extends to Solr's docker image as well. Both are authoritative releases. On Sat, Jul 18, 2026 at 10:51 AM David Smiley <[email protected]> wrote: > On Sat, Jul 18, 2026 at 9:21 AM Eric Pugh <[email protected]> wrote: > >> In PR 204 you will of course see how I am struggling to figure out how to >> map specific jars to specific versions of Solr... If anyone has some good >> ideas, I'm all ears. It's currently a working, but also way to brittle, >> approach. > > > Do you mean, which Solr versions included a specific dependency version? > I didn't see that in the PR but I'm not a python coder. > > The info is in pom.xml but it's a fraught path, I think, to go that > way. You could interroagate Sonatype's API: > https://central.sonatype.org/search/rest-api-guide/ -- search.maven.org. > It seems to be powered by Solr, BTW. That site is where *I* go to get > quick answers to wondering what dependencies does Solr have at a specific > version -- or any Java/JAR artifact out there. I use solr-core typically > but if it relates to a module, I lookup the module. This approach will not > work for a small minority of JARs in Solr's TGZ... like some logging or > maybe Jetty level JARs which conceptually is underneath Solr. In that > respect, perhaps the most comprehensive solution involves a JAR scanner of > each distribution. Basically all JARs self-identify in META-INF inside. >
