Incorrect size and checksums are declared in published Gradle module metadata

[abarsov]

Search before asking

• I searched in the issues and found nothing similar.

Describe the bug

The library jackson-datatype-jdk8-2.18.2 (latest version actally) is published with an incorrect metadata.
jackson-datatype-jdk8-2.18.2.module declares invalid information about the artifact:

"files": [
        {
          "name": "jackson-datatype-jdk8-2.18.2.jar",
          "url": "jackson-datatype-jdk8-2.18.2.jar",
          "size": 35144,
          "sha512": "b2d6e7bee0576dfdeddda2b08df8c17358339bf215f58d82ff1c19f47f8e03537ea92cf328706813508d42fa0a92ac26bb4ee6299324f898b80468e9b29421d7",
          "sha256": "6ae9906a8832103477b97f147e2f93bb3ced41b6a05771cfd767426eb8ddd7b4",
          "sha1": "d85b6fb492cde96f937b62270113ed40698560de",
          "md5": "28be57c48c62d9da0d042475c76da62d"
        }
      ]

The actual parameters of jackson-datatype-jdk8-2.18.2.jar are as follows:

"size": 36161
"sha1": 9ed6d538ebcc66864e114a7040953dce6ab6ea53
"md5": 54d2dc0c44a7188884e8f22fddd947f6

The same story is with some other libraries:

jackson-datatype-jsr310:2.18.2

Hash	Declared in .module	Actual (also published separately in remote repository)
size	131206	132690
sha1	db094a4a836d0d7fcd1586740dfc4c96ffcb6a90	7b6ff96adf421f4c6edbd694e797dd8fe434510a
md5	393122bcfc02c76e898e6a87c094cb24	aaf3adb28aa9de74b3bb87118f93113f

jackson-datatype-guava:2.18.2

Hash	Declared in .module	Actual (also published separately in remote repository)
size	102710	104163
sha1	488a555b80e5b7265818747c884f0100ce4e69d1	7c3184a04f572adab9443e8ef17407f235ac5f4f
md5	4f4b934e1124ac9a6ce2587f26ab1c78	a42adf7d112fea9c584a01eba224e7ec

Version Information

2.18.2

Reproduction

No response

Expected behavior

No response

Additional context

No response

[pjfanning]

@jjohannes would you have any idea what is going on here? Nexus calculates the SHA and md5 checksums when we publish jars. It is your Gradle plugin that calculates them at build time.

[jjohannes]

Thanks for the ping. Yes, the values computed in the plugin. I assume something is wrong there then.

It's no wonder that the checksums differ, if the size differs.

The plugin takes the size from the Jar here: https://github.com/gradlex-org/gradle-module-metadata-maven-plugin/blob/main/src/main/java/org/gradlex/maven/gmm/GradleModuleMetadataWriter.java#L201-L202

There is nothing fancy in the code.

If the uploaded Jar has a different size, this means the Jar the plugin inspects and the uploaded one differ. Maybe the Jar is modified or replaced by another Maven plugin? I know that Maven plugins can do these things and it is a pita for Maven plugin development when it comes to combining plugin 🙁. Any idea if another plugin may cause this? Do we know if this is a new problem or does it exist for longer?

I will have a look. Problem should not be hard to reproduce.

[pjfanning]

@abarsov is this breaking something or is it just that you want this to be correct just because it should be?

I, personally, think we shouldn't bother with these Gradle modules and stick with poms. Grade happily supports poms. If we publish anything other than poms, I think we should support SBOMs which are useful to lots of tooling not just Gradle.

Jackson has lots of git repos and many of these repos have Maven submodules. It is hard to control the order in which the build tasks listed in parent poms and submodules poms run in.

It is hard to validate the Gradle modules. Even if we fix them then later pom changes can break them again.

[jjohannes]

It's not wrong for all Jackson modules. I just checked core and databind and these are correct. The issue is probably less severe than I first thought. It may be caused by interaction with the shade plugin, which caused problems in the past. I'll figure out what's going on and post an update once I got a solution.

[cowtowncoder]

Shade plugin was my first guess, but jackson-datatype-jdk8 does not use it. And it's a relatively small module in general so that's bit odd.
But maybe multi-module Maven projects are ones that are affected (neither jackson-core nor jackson-databind is one); that'd be one obvious difference.

Good luck @jjohannes ! I am hoping to publish 2.18.3 soon so it'd be great to resolve this issue first, if possible.

[jjohannes]

It is not only the shade plugin, but also the moditec plugin. All these plugins (potentially) modify and rely on the pom as well as the jar. They all run in Maven's package phase.

My understanding of this has grown over the years. The order of things in the package phase is important and sensitive as Maven offers no other mechanism to order things there. We should make sure that the order of these plugins is clearly defined and the gradle-module-metadata-maven-plugin always goes last.

This is the list of all the ones that need correction:

  - jackson-dataformat-avro
  - jackson-dataformat-cbor
  - jackson-dataformat-csv
  - jackson-dataformat-ion
  - jackson-dataformat-properties
  - jackson-dataformat-protobuf
  - jackson-dataformat-smile
  - jackson-dataformat-toml
  - jackson-dataformat-yaml
  - jackson-datatype-eclipse-collections
  - jackson-datatype-guava
  - jackson-datatype-hibernate5-jakarta
  - jackson-datatype-hibernate6
  - jackson-datatype-hppc
  - jackson-datatype-jakarta-jsonp
  - jackson-datatype-jaxrs
  - jackson-datatype-joda-money
  - jackson-datatype-jdk8
  - jackson-datatype-json-org
  - jackson-datatype-jsr310
  - jackson-datatype-jsr353
  - jackson-datatype-pcollections
  - jackson-jaxrs-base
  - jackson-jaxrs-cbor-provider
  - jackson-jaxrs-json-provider
  - jackson-jaxrs-smile-provider
  - jackson-jaxrs-xml-provider
  - jackson-jaxrs-yaml-provider
  - jackson-jakarta-rs-base
  - jackson-jakarta-rs-cbor-provider
  - jackson-jakarta-rs-json-provider
  - jackson-jakarta-rs-smile-provider
  - jackson-jakarta-rs-xml-provider
  - jackson-jakarta-rs-yaml-provider
  - jackson-module-afterburner
  - jackson-module-android-record
  - jackson-module-blackbird
  - jackson-module-guice
  - jackson-module-guice7
  - jackson-module-jaxb-annotations
  - jackson-module-jakarta-xmlbind-annotations
  - jackson-module-mrbean
  - jackson-module-no-ctor-deser
  - jackson-module-osgi
  - jackson-module-parameter-names
  - jackson-module-paranamer

I already have an extension of the Gradle integration test ready that gives this list. I'll create a PR tomorrow.

Maybe this is not too complicated to fix, it looks like most "broken" modules have a parent POM involved.

[cowtowncoder]

Yeah those are all multi-Maven-module projects/repos. All also use Moditect for module-info (in Jackson 2.x, 3.0 will not).