Re: [jakartaee-platform-dev] JPMS requirements discussion

[Scott Stark <starksm64@xxxxxxxxx>]

On Jun 8, 2021 at 2:46:27 AM, Mark Thomas <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>

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.

Yes, we agree with that, so ensuring this is unanimous is the first step.

 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.)

I'm talking about guidance as to what should be in there in terms of proper dependencies that use transitive and static requires statements, etc. There is also the notion of a module version that cannot be specified in the module-info.java file currently, but tools like javac and jar can add. Currently the maven compiler plugin adds this by default as of 3.8.1, so that is another item that should be classified as required or not.

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.

It seems clear that the minimum Java SE version for EE10 will be at least SE 11. 

Right, there are requirements that would have to be defined around the use of ModuleLayers in order

for JMPS to be usable with the current deployment class loader scheme in EE, or that would need

to change.

Is the https://wiki.eclipse.org/JakartaEE_Maven_Versioning_Rules

<https://wiki.eclipse.org/JakartaEE_Maven_Versioning_Rules> the agreed

upon naming and versioning conventions that answers the open

https://github.com/eclipse-ee4j/jakartaee-platform/issues/174

<https://github.com/eclipse-ee4j/jakartaee-platform/issues/174> 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.

Mark

There is an OSGi bundle convention issue that should be combined to ensure a consistent name across naming, so thanks for input.