|Re: [jakartaee-platform-dev] JPMS requirements discussion|
On 08/06/2021 16:24, Jason Greene wrote:
On Jun 8, 2021 at 2:46:27 AM, Mark Thomas <markt@xxxxxxxxxx <mailto:markt@xxxxxxxxxx>> wrote:On 08/06/2021 04:11, Scott Stark wrote:The "We need to define the JPMS strategy for EE10 and beyond" issue: https://github.com/eclipse-ee4j/jakartaee-platform/issues/329 <https://github.com/eclipse-ee4j/jakartaee-platform/issues/329> <https://github.com/eclipse-ee4j/jakartaee-platform/issues/329 <https://github.com/eclipse-ee4j/jakartaee-platform/issues/329>> Has a number of comments. My takeaway from the thread is that we need to focus on: 1. Do we required that specification API jars provide a module-info.class description?If we want the JARs to be usable in a JPMS environment, which I assume we do, then the answer has to be yes.This is not technically true. A jar that is a named auto-module (manifest) is certainly usable in a JPMS environment. I would argue the more sensible permission mappings make it significantly more usable.
Is the Manifest entry sufficient if the JAR provides a service via the ServiceLoader or depends on such a service? My understanding was that the manifest approach is not sufficient in that instance and a module-info.class is required.
There may be other JPMS required metadata that can only be provided via module-info.class - the ServiceLoader case is just the one I have come across in the specs I work with.
My expectation is that most API JARs will need to provide more metadata than just an automatic module name in the manifest. If that is not the case then the argument for all API JARs being required to provide a module-info.class may not be as strong as I thought it was. That said, my preference would still be to provide module-info.class files.
Back to the top