Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] JPMS requirements discussion

On 08/06/2021 04:11, Scott Stark wrote:
The "We need to define the JPMS strategy for EE10 and beyond" issue: <>

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.

 2. If yes, what are the requirements for the module-info.class description?

That is defined in the JLS isn't it? (Roughly name plus appropriate directives for requires, exports, opens, uses and provides.)

There are additional discussions in the thread about whether multi-release jars could be produced and whether EE applications could be composed by defining a single application module-info description. I don't see these as in scope for EE10, but feel free to object.

If a project wants to produce a multi-release JAR I don't see any reason why they can't but that can be a per project decision. At the platform level we just need to set the minimum Java version. (Has this been decided yet?)

How modules interact with Jakarta EE is still TBD in my mind. The module system doesn't - as far as I can tell - include the concepts of versioning modules or multiple class loaders. This makes it hard to see how JPMS can be used through out a Jakarta EE container where there may be multiple separate applications each using a different version of the same JPMS module.

Is the <> the agreed upon naming and versioning conventions that answers the open <> issue?

Yes, it is my understanding that those are the agreed naming conventions. However, they do not cover JPMS module names (which I think is the only gap).

My previous suggestion was to use the OSGi Bundle-SymbolicName with any "-" characters replaced by "." but that means names ending in "api" for the spec JARs and there was pushback on that.

It looks like the consensus is to use ${API_PACKAGE} for the JPMS name. I don't think it is necessary but I'd add "... with any '-' characters replaced by '.'" just in case.

As an aside, Apache Tomcat has been using bnd to auto-generate both OSGi and JPMS metadata with reasonable success.


Back to the top