RC9 of jackson-core doesn't contain the module-info.class

Comment From: jafarre-bi

Strange: after deleting the local repository and downgrading to RC8, the JAR also doesn't contain the module-info.class. I've been compiling with RC8 many times without issue. Could these jars have been republished with the missing class?

Comment From: cowtowncoder

Locally I see

META-INF/versions/17/module-info.class

and same for RC9 from Maven Central. I assume it's the same location for jackson-core for all 3.0.0 RCs. This location is bit of a left-over from Jackson 2.x times -- I'd be open for a PR that moves it to /module-info.class if anyone has time to.

The challenge is, if I recall correctly, need to shade in FastDoubleParser. From pom.xml:

      <!-- 10-Jan-2025, tatu: [core#1380] Still need to use Moditect to
         work around bug/misfeature of maven-shade-plugin where it absolutely
         removes root-level `module-info.class`. So use Moditect to put it back
         (but from diff place than with Jackson 2.x)
        -->

(ref: #1380)

Comment From: jafarre-bi

The problem appears to be an incompatibility with maven-compiler-plugin 4.0.0-beta-2. When compiling with this plugin, the module-info class in that location isn't detected. It works with the latest 3.x version.

Comment From: jafarre-bi

The challenge is, if I recall correctly, need to shade in FastDoubleParser. From pom.xml:

<!-- 10-Jan-2025, tatu: [core#1380] Still need to use Moditect to work around bug/misfeature of maven-shade-plugin where it absolutely removes root-level `module-info.class`. So use Moditect to put it back (but from diff place than with Jackson 2.x) -->

(ref: #1380)

A quick search of maven shade plugin module-info results in many entries speaking about excluding module-info.class from shaded jars. This is because the module-info.class files coming from different jars collide and overwrite each other. But it also makes sense. If you mix up packages coming from more than one module, you need a brand-new module-info.java for the result, and the shade plugin can't do that.

I guess Moditect can solve that, but I find it strange that the shade plugin deletes that class, when there are so many cases of people wanting to remove it explicitly. Are you using the option to minimise the shaded jar? In this case, you could try to fool the shade plugin listing module-info or the module name as an entrypoint:

<minimizeJar>true</minimizeJar>
<entryPoints>
  <entryPoint>module-info</entryPoint>
  <entryPoint>my.module.name</entryPoint>
</entryPoints>

But this will probably not work, as the entry points are class names. It may be easier to remove the usage of the shade plugin by incorporating FastDoubleParser's source.

Comment From: cowtowncoder

Alas, entryPoints won't solve the issue: we get one of 3 wrong outcomes:

  1. we get META-INF/versions/17/module-info.class OR
  2. we get nothing (root level module-info.class removed by something; jar or shade plug-in) OR
  3. we get Moditect plugin complaining build is already modular

Comment From: jafarre-bi

I filed a bug to the maven-compiler-plugin project, and now it's clear that the problem is in the plugin, not in Jackson. Thanks for your help anyway.

Comment From: cowtowncoder

Let's hope maven-compiler-plugin can be improved to handle this.

Ideally we can simplify jackson-core module metadata location too in future, but that's sort of orthogonal issue.

Comment From: jafarre-bi

Closed, because the bug is in Maven, not Jackson.