Gradle metadata for jackson-core 2.15.0 adds dependency on ch.randelshofer:fastdoubleparser

[chrisr3]

We have updated our Gradle build to use Jackson 2.15.0, but have noticed that

'ch.randelshofer:fastdoubleparser:0.8.0'

has now been included as a transitive compile dependency. This appears to be due to:

"dependencies": [
    {
        "group": "ch.randelshofer",
        "module": "fastdoubleparser",
        "version": {
            "requires": "0.8.0"
        }
    },

being included in jackson-core-2.15.0.module, which unfortunately is clobbering the contents of the POM.

[pjfanning]

Can you modify your gradle script to exclude it? While we work out how to fix this.

[chrisr3]

Can you modify your gradle script to exclude it? While we work out how to fix this.

We probably have several affected scripts, but we can if we need to. In the meantime, I have also raised this issue.

[pjfanning]

Honestly, gradle should support a flag where you can force pom usage. Just in case.

[cowtowncoder]

I think this is something @jjohannes needs to be looped in.

Also... I wonder why this did not come up during our RC phase. :-(

[chrisr3]

Also... I wonder why this did not come up during our RC phase. :-(

Perhaps all the testing was with Maven?

[cowtowncoder]

@chrisr3 Project itself does not use Gradle, but I'd have expected user base has many Gradle users. But maybe use of Module metadata (GMM) is not quite as wide-spread yet.

But honestly I am getting quite disillusioned by usefulness of RC phase. For any issues that are reported (there are some) there are multiple that aren't until .0 lands. And I am not sure longer RC phase would help either.

Having some integration tests for Gradle side would help of course. I think jackson-integration-tests have some, come to think of that. But not using GMM, I think.

[pjfanning]

Could we reconsider the gradle modules? Gradle works fine with poms. I don't see the real benefit and all this downside about testability of the gradle modules. I haven't added the gradle modules to the Scala module - in large part because I'm bewildered by why do they even exist.

[chrisr3]

Could we reconsider the gradle modules?

Gradle modules claim to provide a "richer" metadata view than POMs do. However, Jackson clearly needs to support both Maven and Gradle equally, and so I don't see that "richer" Gradle metadata being of any use to you. (And particularly seeing as that metadata is wrong here anyway...)

in large part because I'm bewildered by why do they even exist.

My only theory on that subject would be summarised as "Embrace, Extend, Extinguish"... 🤔

[cowtowncoder]

Addition of Gradle module metadata (which Jackson does not use, but provides) was a contribution, meant to improve interoperability. Similar to how OSGi metadata is provided; or Java 9+ module info. As long as there are community members willing to help, I think it makes sense to offer this. And as long as information is not net-negative (breaking use cases).

[pjfanning]

The real impetus is behind SBOMs to provide the richer metadata - like the digests of the dependency jars used in the build. SBOMs are not tied to one build tool - the aim is to support them across the industry. But of course, there are competing SBOM standards (CycloneDX and SPDX, hopefully no other ones).

[cowtowncoder]

Sounds like SBOM could provide improvements in future and as such should be supported. And maybe remove/reduce need for earlier tool-specific metadata approaches.

[jjohannes]

Sorry about this. I also could have thought of this effect when we first encountered problems in combining the maven-shade-plugin and the gradle-module-metadata-maven-plugin.

I think I would have to find a solution in the plugin. To somehow react to the shade plugin and take it's configuration into account.

Just as reminder, this is why we publish the metadata - version alignment through the BOM:
https://blog.gradle.org/alignment-with-gradle-module-metadata

This is something you can not express in POM. Otherwise, I agree that there would be no point in adding the Gradle Metadata on top. I know at least one other library (JUnit5) that also has this feature (but the build with Gradle). The difference here is that we do this although the build is Maven. It was a bit of an experiment to do this back in the day, but it seemed to have worked flawlessly for the first 2 years or so. The issue now is that the shade plugin came into play and combining plugins in Maven is tricky, as there is no clear concept in Maven how plugins can/should interact.

But anyway, if you feel it's not worth the trouble anymore, you could also remove the Gradle Metadata publishing again. Just let me know, as Jackson is the main reason right now for me to further extend that Maven plugin.

What I would do (if I hopefully find the time this weekend):

1. Extend the Gradle integration test we already have to catch such issues
2. Investigate how I can improve the plugin to interact with the shade plugin. And ideally find a satisfying solution and publish a new version.

[pjfanning]

A solution where we can list dependencies to ignore in the gradle module might be an option.

[jjohannes]

Yes I think I have to drop my "Gradle thinking" that I somehow would like this to work automatically. It's not really expected to do it like this in Maven (if I understand things correctly). And even if I would get it working for the shade combination there may be other plugins that cause such issues as well.

I propose to add this:

      <plugin>
        <groupId>de.jjohannes</groupId>
        <artifactId>gradle-module-metadata-maven-plugin</artifactId>
        <configuration>
          ...
          <removedDependencies>
            <dependency>
              <groupId>ch.randelshofer</groupId>
              <artifactId>fastdoubleparser</artifactId>
            </dependency>
          </removedDependencies>
        </configuration>
      </plugin>

Then I would also extend the test so that if in the future another dependency is shaded and it is forgotten to adjust "both places", the test would catch that.

Do you think that would work for you?

[pjfanning]

Seems workable to me

[jjohannes]

Done. I found another issue in the plugin (handling of optional dependencies) through the test. Fixed now and new version is released.

I listed what needs to be done in the different repos in the integration test PR: FasterXML/jackson-integration-tests#19

[cowtowncoder]

I started preparing for fixes with FasterXML/jackson-bom#63 that upgrades GMM plugin version in parent pom.