[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakartaee-platform-dev] [External] : Re: JPMS requirements discussion
|
On 6/8/21 9:46 AM, Mark Thomas wrote:
On 08/06/2021 04:11, Scott Stark wrote:
[..]
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.
+1
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 think this is more about the naming convention to be used.
[..]
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.
The thing is that many specs under Jakarta EE umbrella are usable in
Java SE environment - within EE 10 time frame, the focus can be on this
area. At the end of the day, implementations of the TBD Core profile are
unlikely to provide full-featured server environment as we know it
today. It is more likely that these implementations are based on pure
Java SE while - to some extent - also supporting integration with some
current EE technologies from other, higher-level, profiles. These
implementations should be allowed to make decision on supporting JPMS
themselves and not be blocked by the fact that EE APIs/technologies do
not support JPMS.
Is the
https://urldefense.com/v3/__https://wiki.eclipse.org/JakartaEE_Maven_Versioning_Rules__;!!GqivPVa7Brio!MCf8UQx-F_GdSwfKQwZKNLvc5d3e11cYKHYA2FtnUAj98X72EKeOdLmFs-YBMUCEADw$
<https://urldefense.com/v3/__https://wiki.eclipse.org/JakartaEE_Maven_Versioning_Rules__;!!GqivPVa7Brio!MCf8UQx-F_GdSwfKQwZKNLvc5d3e11cYKHYA2FtnUAj98X72EKeOdLmFs-YBMUCEADw$
> the agreed upon naming and versioning conventions that answers the
open
https://urldefense.com/v3/__https://github.com/eclipse-ee4j/jakartaee-platform/issues/174__;!!GqivPVa7Brio!MCf8UQx-F_GdSwfKQwZKNLvc5d3e11cYKHYA2FtnUAj98X72EKeOdLmFs-YBFtFMBgo$
<https://urldefense.com/v3/__https://github.com/eclipse-ee4j/jakartaee-platform/issues/174__;!!GqivPVa7Brio!MCf8UQx-F_GdSwfKQwZKNLvc5d3e11cYKHYA2FtnUAj98X72EKeOdLmFs-YBFtFMBgo$
> 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).
the wiki should be updated to cover JPMS module names.
thanks,
--lukas
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
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!GqivPVa7Brio!MCf8UQx-F_GdSwfKQwZKNLvc5d3e11cYKHYA2FtnUAj98X72EKeOdLmFs-YBGIv1TvA$
