These are valuable insights Dawid. I looked up and found a BOM for jersey too. The version drift comes from an outdated containers module org.glassfish.jersey.containers:jersey-container-jetty-http that we have to upgrade anyways. I was looking into this some time ago when there was no newer version available to align with the other jersey dependencies.
I have created https://github.com/apache/solr/pull/4244 to address this. On Fri, Mar 27, 2026 at 9:48 AM Dawid Weiss <[email protected]> wrote: > I think this is a larger issue of consistent versioning, somewhere. I > use solr test framework for tests and test dependencies get resolved > to different versions compared to solr-core (transitive) dependencies. > I don't do anything special but I get this in my project: > > ``` > > Multiple versions of the same dependency found in group > 'solr_extensions': > > 1) org.eclipse.jetty:jetty-server > - version 12.0.27 used by: > Configuration testCompileClasspath in :solr-extensions > Configuration testRuntimeClasspath in :solr-extensions > - version 9.4.49.v20220914 used by: > Configuration runtimeClasspath in :solr-extensions > more insight into these dependencies: > gradlew :solr-extensions:dependencyInsight --dependency > "org.eclipse.jetty:jetty-server" --configuration > "testCompileClasspath" > gradlew :solr-extensions:dependencyInsight --dependency > "org.eclipse.jetty:jetty-server" --configuration > "testRuntimeClasspath" > gradlew :solr-extensions:dependencyInsight --dependency > "org.eclipse.jetty:jetty-server" --configuration "runtimeClasspath" > ``` > > The old jetty-server dependency comes from here: > > org.eclipse.jetty:jetty-server:9.4.49.v20220914 > \--- org.glassfish.jersey.containers:jersey-container-jetty-http:2.39.1 > \--- org.apache.solr:solr-core:10.0.0 > \--- runtimeClasspath > > It also applies to other transitive dependencies - I need to manually > force certain versions between the test framework/solrj and the core, > which seems odd. Sorry I can't help with this any more - just wanted > to point out the fact. > > Dawid > > On Thu, Mar 26, 2026 at 10:24 AM Jan Høydahl <[email protected]> > wrote: > > > > Bram, > > > > Would you be so kind to create a new JIRA bug issue for your observation? > > > > You may link it to a related issue SOLR-18003 < > https://issues.apache.org/jira/browse/SOLR-18003> which touches the same > space but had an incomplete fix for 10.0. > > > > Jan > > > > > 7. mars 2026 kl. 08:28 skrev Bram Luyten <[email protected]>: > > > > > > Hi, > > > > > > I've been lurking on the sidelines on your mailinglist since December > > > watching the final steps of the SOLR 10 release, thank you very much > for > > > all the work and congratulations on the release!!! > > > > > > While integrating Solr 10.0.0 as a Maven dependency in our project > > > (DSpace), we discovered that the published POMs for solr-core, > solr-solrj, > > > and solr-api on Maven Central are missing <version> elements for their > > > Jackson 2 (com.fasterxml.jackson) dependencies. > > > > > > Affected artifacts: > > > > > > solr-core:10.0.0 jackson-annotations, jackson-core, jackson-databind, > > > jackson-dataformat-smile, jackson-dataformat-cbor > > > solr-solrj:10.0.0 jackson-databind, jackson-annotations, jackson-core > > > solr-api:10.0.0 jackson-annotations > > > > > > Impact: Maven marks these POMs as invalid and refuses to resolve any > > > transitive dependencies from the affected modules. For solr-core, this > > > means ~50+ transitive dependencies are silently lost (Jersey, > > > OpenTelemetry, Curator, Lucene modules, HPPC, etc.). Projects that use > > > solr-core as a test dependency for EmbeddedSolrServer must manually > declare > > > all of these. > > > > > > Maven warning: > > > [WARNING] The POM for org.apache.solr:solr-core:jar:10.0.0 is invalid, > > > transitive dependencies > > > (if any) will not be available: 5 problems were encountered while > > > building the effective model > > > for org.apache.solr:solr-core:10.0.0 > > > [ERROR] 'dependencies.dependency.version' for > > > com.fasterxml.jackson.core:jackson-annotations:jar is missing. > > > [ERROR] 'dependencies.dependency.version' for > > > com.fasterxml.jackson.core:jackson-core:jar is missing. > > > [ERROR] 'dependencies.dependency.version' for > > > com.fasterxml.jackson.core:jackson-databind:jar is missing. > > > [ERROR] 'dependencies.dependency.version' for > > > com.fasterxml.jackson.dataformat:jackson-dataformat-smile:jar is > missing. > > > [ERROR] 'dependencies.dependency.version' for > > > com.fasterxml.jackson.dataformat:jackson-dataformat-cbor:jar is > missing. > > > > > > Root cause (likely): Solr 10 uses Gradle for building and uses a > Jackson 2 > > > BOM (jackson-bom) for version management. The Gradle maven-publish > plugin > > > generates the POM from the Gradle model, but BOM-managed versions are > not > > > resolved/flattened into the published POM. Since the published POM has > no > > > <parent> element, there is no BOM to fall back on at consumption time. > > > > > > Workaround: Projects that depend on solr-core (e.g. for testing with > > > EmbeddedSolrServer) must explicitly declare all dependencies that would > > > normally come transitively through solr-core. In our case this meant > adding > > > ~20 explicit test dependencies to match what solr-core would have > provided. > > > > > > Would it be worth creating a JIRA for this? The fix would likely > involve > > > either adding explicit versions to the Gradle dependency declarations > for > > > Jackson, or configuring the maven-publish plugin to resolve BOM-managed > > > versions when generating POMs. > > > > > > Thanks, > > > > > > Bram Luyten, Atmire > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
