SOLR-18185: POMs: publish resolved version

[dsmiley]

of dependencies.
Fixes ambiguous/missing version problems for clients.

https://issues.apache.org/jira/browse/SOLR-18185

Note: this was extracted from PR #4227 , which is how I confirmed that there was a problem and now isn't gone.

[janhoy]

This is already above my pay grade :) A bit worried that our new gradle version catalog seems to be more "fluent" than our previous consistent-versioning plugin which locked same lib on one version across the board. This PR may help with aligning the maven build with gradle, but is this a patch for something more fundamental that shuold be changed?

I'll kick off Copilot for 2nd opinion as I don't have anything to add at this point.

[Copilot]

Pull request overview

Updates Solr’s Maven publication configuration so generated POMs publish resolved (locked) dependency versions, avoiding ambiguous/missing versions for downstream consumers (SOLR-18185).

Changes:

• Enable Gradle versionMapping for Maven publications to publish resolved dependency versions.
• Add an unreleased changelog entry describing the publishing behavior change.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
gradle/maven/defaults-maven.gradle	Adds Maven publication version mapping so POMs emit resolved/locked versions instead of catalog-declared versions.
changelog/unreleased/SOLR-18185-pomPublishVersions.yml	Documents the change in published POM dependency version behavior.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[dsmiley]

This PR doesn't have to do with version alignment; it doesn't affect anything within our project. If it did, then our lockfiles would have been tickled here.

This PR is about what users of our dependencies get. Before they would have POMs & gradle-metadata that sometimes lacked a version or that which provided a range of versions. Our build may have custom dependency resolution rules that help within our project but that which don't get published. Now, users should consistently be getting a specific (thus unambiguous) version -- in fact the same version our project uses.

IMO Gradle ought to simply do this by default.

https://docs.gradle.org/current/userguide/publishing_maven.html#publishing_maven:resolved_dependencies

[malliaridis]

This looks good to me, and according to the gradle docs like the right thing to do.

Have you also considered including only the missing platform dependency as menzioned in step 3 here, or add that in addition to your changes?

I am asking because I consider both good additons / fixes, regardless of them solvinh thr issue in different ways (yours more reliable than mine).

P.S. I won't be able to test the change before sunday, but dont let it keep you from merging it.

[dsmiley]

Do you refer to?:

3. add implementation platform(libs.fasterxml.jackson.bom) to the
   solr-core's build.gradle dependencies

Whether we do that or not, IMO should be separate from this PR, which is very focused. This PR probably makes it pointless to transitively publish BOMs of Solr's dependencies (like Jackson).

[malliaridis]

Yes, that's what I'm referring to. Separate PR makes sense, yeah. I may have a look once I find some time and see if a PR would have any value.