You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@solr.apache.org by "janhoy (via GitHub)" <gi...@apache.org> on 2026/03/09 18:21:53 UTC
[PR] Potential solution to Maven POM generation issue [solr]
janhoy opened a new pull request, #4199:
URL: https://github.com/apache/solr/pull/4199
Ref https://lists.apache.org/thread/w0tqdcjyo0wlbf7xjtc0ll9tjhwor8n2
I asked Claude to analyze and fix. This was the result.
### Problem
Maven consumers of `solr-api`, `solr-solrj`, and `solr-core` 10.x get invalid POM errors:
```
[ERROR] 'dependencies.dependency.version' for com.fasterxml.jackson.core:jackson-annotations:jar is missing.
[WARNING] The POM for org.apache.solr:solr-core:jar:10.x.x is invalid, transitive dependencies (if any) will not be available
```
Jackson dependencies in `gradle/libs.versions.toml` have no pinned version — they rely on the
Jackson BOM for version resolution at Gradle build time. Gradle's `maven-publish` plugin faithfully
omits `<version>` from the generated POM for such entries, since from Gradle's perspective the BOM
import in `<dependencyManagement>` should cover it.
However, Maven's model validator rejects POMs where `<dependencies>` entries lack `<version>`
elements, even when a BOM import is present — particularly `solr-core`, which has no Jackson BOM
entry in its `<dependencyManagement>` at all (its internal platform entry is stripped during POM
generation).
### Fix
Extend the existing `pom.withXml` block in `gradle/maven/defaults-maven.gradle` to post-process
generated POMs: after the internal platform removal, collect all Gradle-resolved artifact versions
from `compileClasspath`/`runtimeClasspath`, then inject explicit `<version>` elements for any
`<dependency>` entry that is missing one.
This uses the actual BOM-resolved versions (e.g. `jackson-annotations:2.20`,
`jackson-core:2.20.1`, `jackson-databind:2.20.1`) and applies centrally to all published modules
without requiring version pinning in `libs.versions.toml` or changes to individual `build.gradle`
files.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Potential solution to Maven POM generation issue [solr]
Posted by "janhoy (via GitHub)" <gi...@apache.org>.
janhoy commented on PR #4199:
URL: https://github.com/apache/solr/pull/4199#issuecomment-4026939722
> I wonder what smoketest / validation might verify the result?
Isn't it strage that Maven Central accepted our maven artifacts without warnings (or did it?).
This open JIRA https://issues.apache.org/jira/browse/SOLR-18069 is in the same alley. The suggestion is to add a step to smoke tester that downloads maven artifacts and tries to use them in a mini project with maven, which will resolve and catch many kids of potential issues I guess.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Potential solution to Maven POM generation issue [solr]
Posted by "bram-atmire (via GitHub)" <gi...@apache.org>.
bram-atmire commented on PR #4199:
URL: https://github.com/apache/solr/pull/4199#issuecomment-4026934243
> I wonder what smoketest / validation might verify the result?
As a downstream Maven consumer (DSpace, upgrading to Solr 10 for Spring Boot 4 compatibility), here's what we observed:
The impact is more severe than it may appear: Maven doesn't just skip the versionless Jackson dependencies. When Maven's model validator marks the POM as invalid, it drops all transitive dependencies from the affected module (~50+ for solr-core), not just the ones missing <version>. Our workaround was to explicitly declare all solr-core transitive dependencies in our own POM, which is brittle and maintenance-heavy.
**For a smoketest**: a minimal Maven pom.xml that depends on the published solr-core artifact, followed by mvn dependency:tree -Dverbose, would catch this immediately. If Maven emits "The POM for org.apache.solr:solr-core:jar:10.x.x is invalid, transitive dependencies (if any) will not be available", the published POM is broken. This could be a post-publish CI step.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Potential solution to Maven POM generation issue [solr]
Posted by "dsmiley (via GitHub)" <gi...@apache.org>.
dsmiley commented on PR #4199:
URL: https://github.com/apache/solr/pull/4199#issuecomment-4026120634
I wonder what smoketest / validation might verify the result?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Potential solution to Maven POM generation issue [solr]
Posted by "janhoy (via GitHub)" <gi...@apache.org>.
janhoy commented on PR #4199:
URL: https://github.com/apache/solr/pull/4199#issuecomment-4026757864
Agree this may fix a symptom, not the cause. Is this related to our discussion lately where the «platform» module is not aware of BOMs and thus we needed the workaround in gradle to help it use the BOM versions?
Perhaps the proper fix is to publish a parent/platform POM for Solr to have a location for all our BOMs? Dunno.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org