The entry in MANIFEST.MF is so that the automatic module name isn’t generated from the JAR file name. This enables you to start modularizing before all of the dependencies are modularized etc.
The module-info.java and OSGi configurations should be able to co-exist. Unless you load a dependency on the module-path, the module-info is ignored.
I would like to see Jakarta EE dependencies provide a module-info so that you could use them in a modularized Java SE application. I don’t think it makes sense to say that JPMS is the module system to be used by containers (would wreak havoc).
Note: I don’t think I was the one that added JPMS to the list so I don’t mean to speak for whoever added it.
-Ryan
Hi, Not being too familiar with OSGi, could we include module definitions for both?
Most every component already contains at least OSGi definitions since both GlassFish and Open Liberty depend on these. There's an extra header in the MANIFEST.MF for the JPMS automatic module name. Some components started to use that, but I think most are still waiting for an official guidance from the platform for that. I haven't tried JPMS much, so I don't know how much module-info will conflict or not.
Kind regards, Arjan
|
