Gradle reports incorrect jackson-bom dependency version

[five-iron]

See this issue for reference: FasterXML/jackson-databind#3428

I think the cause of this is due to the configuration of gradle-module-metadata-maven-plugin in jackson-base pom.xml:

<plugin>
  <groupId>de.jjohannes</groupId>
  <artifactId>gradle-module-metadata-maven-plugin</artifactId>
  <version>0.2.0</version>
  <executions>
    <execution>
      <goals>
        <goal>gmm</goal>
      </goals>
    </execution>
  </executions>
  <configuration>
    <platformDependencies>
      <dependency>
        <groupId>com.fasterxml.jackson</groupId>
        <artifactId>jackson-bom</artifactId>
        <version>${project.version}</version>
      </dependency>
    </platformDependencies>
  </configuration>
</plugin>

${project.version} only works if the jackson-bom version matches the downstream project. E.g., if jackson-databind is at version 2.13.2.1 while jackson-bom is actually at 2.13.2.20220324, gradle will mistakenly report the jackson-bom dependency as 2.13.2.1, which there is no version for, and so it fails.

I'm not sure the best solution, but maybe this needs to be hardcoded to the same version as jackson-bom above, and changed with each release/snapshot cycle? Or maybe a variable or something in this file.

[cowtowncoder]

@jjohannes would be the person who knows, I think. Micro-patch handling is tricky, not sure what could be done here.

[jjohannes]

If the version number of micro-patch releases are not aligned -- which I was not aware of when adding the above configuration -- I would suggest to alway link to the latest major.minor version of the BOM. You can still upgrade individual components to their micro-patch release then. Or use one of the newer BOMs directly.

Would that make sense?

<version>${majorMinorVersion}</version>

We have to figure out how to get hold of majorMinorVersion I don't know how to do that in maven and if it is simple.

[cowtowncoder]

@jjohannes Just to make sure I understand: are you suggesting that jackson-databind version 2.13.2.1 should simply refer to jackson-bom of 2.13.2?
That is something I could consider and would likely work.

But there is one related aspect that I'd like to ensure works as well: from users perspective there is benefit from bom that would have the combination of jackson-databind:2.13.2.1 and everything else at 2.13.2.0.
So what I am thinking of would be to still release such a BOM but not refer to it from jackson-databind.
Would this work? So, literally just:

1. Publish jackson-databind:2.13.2.1 with parent pom of jackson-base:2.13.2 (which then refers to jackson-bom:2.13.2)
2. Publish jackson-bom:2.13.2.[timestamp] (and jackson-base) with managed dependencies of (1)

This would allow users to refer to BOM from (2) but without creating inconsistent loop for (1).

One possible kink, though, is this: jackson-bom:2.13.2 does specify managed dependency 2.13.2 for jackson-databind. I don't know if that matters -- it shouldn't, right? -- but thought worth pointing out.

[cowtowncoder]

I guess I may be overthinking this, fwtw, since I am not only considering module plugin but more generally version resolution by tooling. This is due to my non-OSS work where for a while I was working on figuring out how transitive dependencies are resolved, vulns reported against them, possible automated upgrades and such. This is a rather complicated area (as I am sure everyone participating here knows :) ) due to version conflicts that transitive closure brings in -- and then different strategies in selecting the "real" version.
Various tools have their own views, too; my (naive?) view is that Gradle takes the "latest version wins" approach whereas Maven attempts to find "the closest reference": this is challenging because it is common for there to be more Maven metadata that Gradle tooling needs to use -- so which logic should be applied.

Having said that it does seem to me that what I outline above would be workable. I will try to verify this locally and then think I'll proceed with 2.12.6.1 release.

And given the metadata issue I may (have to) consider releasing otherwise change-less jackson-databind version 2.13.2.2 (no, not ready to go for 2.13.3, not enough fixes as per https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.13.3) to get to working metadata.

[jjohannes]

@cowtowncoder yes what you describe works. And it it basically what I tried to say. I only missed the parent pom part, which ist a nice solution I think.

And yes. A user can still use the jackson-bom:2.13.2.[timestamp] version directly in Gradle and it will work (user will get jackson-databind:2.13.2.1) because Gradle picks the higher version.

If you want to go with that solution but still run into issues, let me know.

[jjohannes]

I think the "best" solution in genreal would be to not have timestamp BOMs, but instead have a BOM for each micro version.

So for the current situation there would be a BOM 2.13.2.1 which refers to jackson-databind:2.13.2.1 and to version 2.13.2 of all the other components for which there is no micro patch. Then the jackson-databind:2.13.2.1 metadata would work as it is now.
But I don't how easy (or if at all) that can be realized with the current setup.

[cowtowncoder]

@jjohannes I think date-based (realized "timestamp" is bit misleading) may actually better solution personally, for the main use case: extending set of boms for otherwise closed branches. Problem with attempts to use full 4-digit version is that this is not only more complicated to handle (2.13.2.3 of jackson-databind along with 2.13.2.1 of jackson-dataformat-xml, latter of which is released after former, for example, is a possibility) but gives wrong impression of there being a full set of components. Use of date only offers sorting to indicate "which BOM is later" (and has more up-to-date set).

I guess it would be possible to just increment bom micro-patch version, but honestly I also do not see any benefit to the user: you cannot really arbitrarily increase that number but have to use some specific version. And for that date-based version works fine, see f.ex:

https://mvnrepository.com/artifact/com.fasterxml.jackson/jackson-bom

as long as there's no mixing of sequence numbers and date-based.

Be that as it may, at this point I will not be changing this aspect. But I will proceed to change the way micro-patch - to -base/bom works to make GMM generation succeed.

[cowtowncoder]

Hmmmh. Actually. Looking at generated

target/publications/maven/module.json

I am not sure things work any better with "bom" of 2.13.2 (or similar patch-level only) approach. :-(

[cowtowncoder]

Ok. But would the fix not be as simple as using this:

  <configuration>
    <platformDependencies>
      <dependency>
        <groupId>com.fasterxml.jackson</groupId>
        <artifactId>jackson-bom</artifactId>
        <version>${project.parent.version}</version>
      </dependency>
    </platformDependencies>
  </configuration>

i.e. replace ${project.version} with ${project.parent.version}?
That seems to work if used directly from the project (I am modifying pom.xml of jackson-databind); not 100% sure yet if it'd work from jackson-bom/base/pom.xml.

Will propose a patch against 2.13 soon.

[cowtowncoder]

@jjohannes I published jackson-databind version 2.12.6.1 with the definitions I suggested. Is there an easy way to see whether resulting .module file works as expected and validates? It seems legit to me but I am slightly worried about possible discrepancy between versions 2.12.6 (that referenced jackson-bom defines for jackson-databind) and 2.12.6.1 (that referencing jackson-databind has as version).

[jjohannes]

@cowtowncoder thanks I tested it (see comment on the other issue) and it works!

And yes <version>${project.parent.version}</version> looks good. I missed that you'll need that (I do not speak Maven that well :) )

If you ever want to test something manually yourself. You can do:

1. Create a folder with two empty files settings.gradle.kts and build.gradle.kts
2. Put his into build.gradle.kts

plugins {
    id("java-library")
}

repositories {
    mavenCentral()
}

dependencies {
    // change dependencies and versions here to see effects
    implementation(platform("com.fasterxml.jackson:jackson-bom:2.12.6.20220326"))
    implementation("com.fasterxml.jackson.core:jackson-databind")
    implementation("com.fasterxml.jackson.dataformat:jackson-dataformat-protobuf")
}

3. Run gradle :dependencies --configuration compileClasspath --scan

You can look at the dependencies tree printed to console or open the Build Scan Link and explore the results in the browser.