[
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:
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.
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 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
