Skip to main content

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


 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;!!GqivPVa7Brio!MCf8UQx-F_GdSwfKQwZKNLvc5d3e11cYKHYA2FtnUAj98X72EKeOdLmFs-YBMUCEADw$ <;!!GqivPVa7Brio!MCf8UQx-F_GdSwfKQwZKNLvc5d3e11cYKHYA2FtnUAj98X72EKeOdLmFs-YBMUCEADw$ > the agreed upon naming and versioning conventions that answers the open;!!GqivPVa7Brio!MCf8UQx-F_GdSwfKQwZKNLvc5d3e11cYKHYA2FtnUAj98X72EKeOdLmFs-YBFtFMBgo$ <;!!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.


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.

jakartaee-platform-dev mailing list
To unsubscribe from this list, visit;!!GqivPVa7Brio!MCf8UQx-F_GdSwfKQwZKNLvc5d3e11cYKHYA2FtnUAj98X72EKeOdLmFs-YBGIv1TvA$

Back to the top