Publish Gradle Module Metadata as configured in jackson-base

[jjohannes]

See: FasterXML/jackson-bom#33

[cowtowncoder]

Quick question here: is this used by a tool, or just informational? Is there a link to something that explains it (could be in different comment if so)? Would be nice to have something for curious minds :)

[jjohannes]

Yes. This line is discovered by Gradle so that it knows that a .module file was published.

If you publish with Gradle, where the POM is generated, you actually get more explanation on the comment. I now added the whole explanation here as well.

[cowtowncoder]

Looks good, just need CLA (as per comment in PR for jackson-bom) and will merge.

Now, one question on verification: do you think it would possible to create (junit) test(s), possibly in separate project, to verify goodness of added metadata? Test project could use gradle, just another repo under FasterXML, which I could add daily build from Travis, to check that major components of matching minor version (that is, repo would have same branches as Jackson components) would build daily. I have something similar already:

https://github.com/cowtowncoder/jackson-compat-minor

except not automated via daily cron builds, and focused on cross-minor version checks (not very good attempt, but I try to at least check how dataformats work).

The reason I am thinking of adding such repo is that there is currently no automated way to even check that changes in jackson-core or jackson-databind do not break functionality in other Jackson components, without manual build. Signature changes can be caught by IDE (if I have projects open), but not behavioral changes. Regular Travis builds only build component that has changed, not dependencies (it wouldn't know).
But having separate "integration test" project could achieve that, and even if there is some delay (up to 24h), it would tighten the test loop, and reduce need to do constant local builds.

Given possible existence of such project/repo, it'd be great if Gradle module metadata fitness could also be verified (similarly OSGi, if possible, but I'd need help with that too).

[jjohannes]

@cowtowncoder I think it is a very good idea to have such an integration test repo and I am happy to contribute a test that runs Gradle to verify that version selection/alignment works as expected. The test can then also cover both cases of using only the POM data (Gradle 5 and below) and the richer metadata (Gradle 6).

I have a PR for Guava open, where I also added a test like that.