Staus on module-info for MP APIs + 5 things to settle once for the six

22 views
Skip to first unread message

ant...@sabot-durand.net

unread,
Sep 6, 2026, 10:30:44 AMSep 6
to MicroProfile

Hi all,

As said in a previous thread, I proposed PR for the six specification we are using in Vidocq to add module-info in their API.

The six PRs are up and green (first human feedback on FT, thanks Ladislav & Andrew):

The companion issues each have a comment on what moved between proposal and descriptor. More friction than expected, so a few things I'd rather settle here than in six threads.

1. requires static transitive for the Jakarta modules

Most of these APIs only touch Jakarta through their annotations (interceptor bindings, qualifiers, the odd AnnotationLiteral); the programmatic types are plain Java. All six PRs currently declare jakarta.cdi / jakarta.inject / jakarta.interceptor as requires static transitive: same at compile time, optional at resolution, readability propagated when a container is around. The alternative is plain requires transitive, which matches how these APIs are actually used (always inside an MP runtime). The practical difference is close to nil either way; it's a taste call and I'd like one answer for the six. Hard deps (jakarta.json for JWT, jakarta.ws.rs / jakarta.annotation for Rest Client) stay plain requires transitive regardless.

2. Java 8 bytecode for a Java 11 platform

Config, FT and JWT are still on parent 2.x (--release 8). Since module-info.class is Java 9 bytecode, that costs a second compiler execution with --release 9 + --patch-module, a v53 class at the jar root next to v52 ones (SLF4J 2.x layout — legal, but meh), and on FT an explicit jakarta.interceptor-api 2.1.0 because the 2.0.0 pulled by CDI 3.0 has no module name. I kept the PRs mergeable in a minor (Java 8 target untouched), but Ladislav's suggestion to bump to parent 3.x is the clean fix. Question for those three projects: do you want the bump, and is it really a major given no supported MP platform runs on Java 8? (For Config the question is moot if it moves to the Jakarta EE 12 Core Profile as discussed — the descriptor is then just for the remaining life of the 3.x line.)

3. Same build wiring on all six, Java 11 included — worth moving to the parent?

I expected the parent 3.x projects to just drop module-info.java in src/main/java. Not possible without touching the OSGi side, which is off the table (Liberty & co. rely on it): the package-info.java files carry @org.osgi.annotation.versioning.Version (+ @ProviderType in Rest Client), and the annotation jars have neither a descriptor nor an Automatic-Module-Name, so in module mode the descriptor would have to requires static a filename-derived automatic module — not in a spec API. So the descriptor is compiled around the existing build instead: src/main/module-info/, dedicated execution at process-classes with --patch-module, build-helper for the sources jar, javadoc pinned to class path mode. OSGi annotations, bnd headers and the main compilation are untouched. It works, but it's ~60 lines of POM copy-pasted six times — a natural candidate for microprofile-parent (pluginManagement or a profile keyed on src/main/module-info) so each spec only adds the descriptor file. I can open that PR if there's appetite.

4. Names & dependency hygiene

Descriptors use org.eclipse.microprofile.<spec>. For the five APIs that had no name, this breaks anyone doing requires microprofile.health.api; today — right call IMO, but release-notes material. Related: Rest Client needs requires static org.eclipse.microprofile.config, which only became possible with Config 3.1.1 (3.1 had no Automatic-Module-Name); same story as interceptor-api above. Once the APIs are real modules, their deps need stable names too — an Automatic-Module-Name in service releases of older lines is a cheap stopgap. And when Config becomes a Jakarta spec, that edge simply follows the new module name (it's internal, non-transitive), so no consumer impact.

5. Testing the descriptor

Only Rest Client has one (ModuleDescriptorTest: reads the compiled descriptor, asserts name / exports / uses / exact requires sets) — simply because its api module was the only one with an existing test setup. It caught the missing Config edge, which would have been an IllegalAccessError at run time, and it'll flag the Config → Jakarta rename the day it happens. Adding it to the other five means introducing surefire + a test dependency in api modules that have none today; happy to do it if wanted.

1 and 2 are the ones I'd really like a decision on; the rest is FYI / offers.


Regards,

Antoine Sabot-Durand




Emily Jiang

unread,
Sep 8, 2026, 4:55:17 AMSep 8
to microp...@googlegroups.com
Thank you, Antoine, for the detailed information! Here are my thoughts.
1. I prefer the option `Require Transitive` as it reflects the real usage.
2. I think this makes sense for these specs to move up their Java version. However, according to the versioning policy, this would require a major release of these specs. 
3. I prefer to move the spec pom changes to the parent pom to reduce the duplication.
4. Adding an Automatic-Module-Name to the service release sounds reasonable.
5. If you can add a test, it would be great. However, this should be a unit test and should not force the runtime to pass the test if it is a runtime test. I took a look at the Rest Client PR and thought it was just a Junit and tested the api jar.
Please join next week's MP live hangout to discuss further on the topic. You can find the meeting time here
Thanks,
Emily



--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/microprofile/9d60458f-bfd3-49fb-83b2-118059f9bd07n%40googlegroups.com.


--
Thanks
Emily

Reply all
Reply to author
Forward
0 new messages