Gradle consumers issue

[elect86]

Gradle has a known issue when it comes to bom, it can't properly resolve dependency versions which have more than one layer of indirection

In my case, that is jackson.version.module.kotlin in jackson-bom-2.16.1

<jackson.version>2.16.1</jackson.version>
<jackson.version.module>${jackson.version}</jackson.version.module>
<jackson.version.module.kotlin>${jackson.version.module}</jackson.version.module.kotlin>

Could not resolve all dependencies for configuration ':webstartRes'. Could not find com.fasterxml.jackson.module:jackson-module-kotlin:.

If jackson.version.module.kotlin had ${jackson.version}, then it'd work fine instead

How to fix this?

1. Switch to Gradle Platform, this will generate .pom for Maven users and .module for Gradle ones
2. Leave the current Maven implementation as it is and simply inject within it a Gradle .module file generation and include that in the publication, as I did with pom-Scijava, where you have platform (and catalog, if you want) published altogether at the very same coordinates.

I can provide a PR for either of them

[cowtowncoder]

First of all, thank you for reporting this @elect86.

Ideally, of course, Gradle tooling didn't have this limitation. But it sounds like that this is not going to happen?

Now... I have no plans to move to Gradle so (1) won't work.

(2) might work, but depends a bit on complexity of the approach. If it's easy to show in form of PR I'd be interested.

But... alternatively maybe just going with the simplest (in some sense) choice of just flattening versions to remove use of intermediate jackson.version.module.kotlin -- we probably still need to leave that property available (if some Maven users did use it), but not use it. So changing things to:

<jackson.version>2.16.1</jackson.version>
<jackson.version.module>${jackson.version}</jackson.version.module>
<jackson.version.module.kotlin>${jackson.version}</jackson.version.module.kotlin>

Note, too, that the oldest branch from which full releases are likely is 2.17 (full patch release takes 2.5 - 3 hours to make so I have to choose where to spend my time for maximum benefit). So PR probably should be against 2.17

[elect86]

That's actually the simplest solution, yes

I'll craft one with that then

[cowtowncoder]

Great! Also please add an XML comment or two to indicate reasoning (and if there's a link to Gradle platform limitation, that'd be great)

[jjohannes]

Gradle has a known issue when it comes to bom, it can't properly resolve dependency versions which have more than one layer of indirection

Which known issue are you referring to @elect86? Can you give a pointer to the issue in Gradle's issue tracker.

I am not aware of such a problem and are a bit skeptical that it exists. Because I would imagine that it would have caused a lot of trouble with multiple libraries in the past. But I am happy to be educated.

In the case of the Jackson BOM, there is testing in place that resolves the BOM with Gradle and then uses that information to validate the Metadata of the Jackson modules. If there were an issue with missing versions, I am pretty sure we would have noticed.

[elect86]

I am not aware of such a problem and are a bit skeptical that it exists. Because I would imagine that it would have caused a lot of trouble with multiple libraries in the past. But I am happy to be educated.

Sorry for the late reply

I experienced multiple times Gradle failing to resolve a double indirection

The first one was with the scijava-bom, here, I recall we discussed it with @Vampire (do you recall all of this?) on Slack

Then he tried to fix this by creating a custom ComponentMetadataRule here to force Gradle aligning the jna dependency using the 2-layer variable to be aligned to the main jna.version, but that didn't work neither and that's why we opened that issue

[Vampire]

No, I don't remember what we talked about in detail 5 years ago. Maybe you can look up the conversation for reference in the Linen archive of the Gradle Slack. 🤷‍♂️

[Vampire]

That issue has nothing to do with a double-indirection though as far as I remember, but simply that the version aligning does require any version to be used at all.