Repository navigation
Set ModulePackages in our jar's module-info #8600
Description
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.
Activity
DragonFSKY commentedon Aug 12, 2026
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
ModulePackagesattribute inmodule-info.class, and add an artifact-level test to verify it. Would this be a welcome contribution?cpovirk commentedon Aug 15, 2026
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 commentedon Aug 16, 2026
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 commentedon Aug 16, 2026
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-plugininstead ofmaven-jar-plugin. (And maybemaven-bundle-plugindoesn'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 (.exesuffix,/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 thanverify, 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 thepom.xmleasier 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 commentedon Aug 17, 2026
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!
abhinav-phi commentedon Sep 11, 2026
Picking this up after the last two attempts stepped back — the sticking point in this thread isn't the attribute, it's finding a build-native hook (exec-maven-plugin is out for the JDK/Windows/IDE reasons raised above).
I'll start from the hypothesis already in-thread: the gap is that maven-bundle-plugin assembles the jar without going through the
jartool, soModulePackagesnever gets computed. First step is checking whether current bnd can be told to emit it directly for the bundledmodule-info.class, and whether the plexus-archiver behavior referenced above is reachable via amaven-bundle-plugin/bnd version bump — i.e. preferring the "our build is more normal" direction over any post-processing step.To keep it to "straightforward vs not" as decided in advance: rather than open a speculative PR, I'll build the
guavajar locally and post the actual diff plusjava --describe-module --file guava.jaroutput showingModulePackages(and what it costs the build) before anything is merged. If the honest answer turns out to be "requires a significant build complication", I'll say so here and walk away the same way.cpovirk commentedon Sep 25, 2026
There's a chance that apache/maven-jar-plugin#484 will address this for
maven-jar-plugin. But as discussed, we're usingmaven-bundle-plugin.maven-bundle-pluginhas given us trouble before (and again when we arguably should have known better), so it's possible that we'd migrate off if doing so would fix theModulePackagesissue. Or maybemaven-bundle-pluginwill follow suit.abhinav-phi commentedon Sep 28, 2026
following up on my Sep 11 note, checked all the upstream states instead of a speculative PR, and the honest answer is nothing is simple today:
ModulePackages.ModulePackages(bndtools/bnd#4399, fixed 2020), but only when bnd generates the module-info from OSGi metadata. our hand-written javac-compiled module-info just gets copied through, and there's no instruction to enhance an existing one.also confirmed on the shipped jar: 33.5.0-jre's
module-info.classcarries onlyModuleandPackageattributes, noModulePackages.so the cost today is a build migration rather than a pom tweak, which fails your "straightforward" bar. stepping back... will re-check when maven-jar-plugin 4.x gets a release, and reopen with the local diff at that point if it's actually cheap then.