Set `ModulePackages` in our jar's `module-info`

[cpovirk]

I noticed in jspecify/jspecify#866 (comment) that JSpecify does not include a ModulePackages attribute in its module-info.class. That got me to check Guava, and sure enough, we don't include one here, either. That's probably for similar reasons: Maven builds the jar itself, without using jar, which would automatically modify module-info.class to include that attribute (I think).

My understanding is that ModulePackages is merely an optimization, possibly even only at runtime, not compile time, but I'm not sure of that. Still, it would presumably be a nice optimization to unlock someday.

[DragonFSKY]

Hi, I’m interested in working on this issue. My initial thought is to update the build configuration so that the final Guava JAR includes the ModulePackages attribute in module-info.class, and add an artifact-level test to verify it. Would this be a welcome contribution?

[cpovirk]

Unfortunately, I think it's hard to know in advance: If it's something that's fairly straightforward, then we'd probably go for it. But if it's a significant complication to the build, then probably not.

[Mr-Vishal-Ranjan]

Hi, I looked into this and found that adding an exec-maven-plugin execution in the verify phase to run jar --update --release 9 -C target/classes module-info.class after the maven-bundle-plugin assembles the JAR is enough to inject the ModulePackages attribute. Tested it locally and it works. Should I go ahead with a PR?

[cpovirk]

Thanks.

I wonder if Maven would be doing this automatically if our build were more "normal." Maybe the problem is related to what you said, which is that we use maven-bundle-plugin instead of maven-jar-plugin. (And maybe maven-bundle-plugin doesn't use the Plexus archiver, or maybe it's on an old version that we could upgrade?) That has confused me before.

I always worry a bit about exec-maven-plugin: It might use a different (and less predictable) JDK version than the rest of the build, it might not work on Windows (.exe suffix, / vs. \??), and it might integrate less well with IDEs.

I also don't trust my knowledge of Maven build phases. I suspect that we'd want package—possibly with careful plugin ordering—rather than verify, but I don't know for absolute certain. And then I worry about the "careful plugin ordering" bit, especially since we've tried to make the pom.xml easier to navigate by alphabetizing the plugins.

It's possible that we should look at something like moditect-maven-plugin, but I also worry about new plugins in general. That particular one hasn't had a commit in a year, and while that might be totally fine, it's a reminder of one of the dangers, especially for a project like Guava that tries to stick to newer Java versions to pick up bug fixes and other improvements.

So I think I'd want something even simpler than exec-maven-plugin.

[Mr-Vishal-Ranjan]

Fair points all around, honestly hadn't thought about the JDK version mismatch or the Windows edge cases, so thanks for spelling that out.

I looked into it a bit more but I'll be upfront: my Maven knowledge has limits, and I don't want to propose something that looks fine on the surface but quietly breaks things in CI or on someone's machine. The exec-maven-plugin path felt simple at first but it clearly has enough sharp edges to not be worth it.

From what I can tell the real issue is that maven-bundle-plugin assembles the JAR itself without going through the JDK's jar tool, so ModulePackages never gets written into module-info.class. But finding a clean hook for that is probably a job for someone who knows the Maven build lifecycle inside out.

Since nothing is actually broken right now I'll leave it here. Learned a lot about the build setup digging into this though!