[
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 16:24, Jason Greene wrote:
On Jun 8, 2021 at 2:46:27 AM, Mark Thomas <markt@xxxxxxxxxx
<mailto: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>
<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.
This is not technically true. A jar that is a named auto-module
(manifest) is certainly usable in a JPMS environment. I would argue the
more sensible permission mappings make it significantly more usable.
Is the Manifest entry sufficient if the JAR provides a service via the
ServiceLoader or depends on such a service? My understanding was that
the manifest approach is not sufficient in that instance and a
module-info.class is required.
There may be other JPMS required metadata that can only be provided via
module-info.class - the ServiceLoader case is just the one I have come
across in the specs I work with.
My expectation is that most API JARs will need to provide more metadata
than just an automatic module name in the manifest. If that is not the
case then the argument for all API JARs being required to provide a
module-info.class may not be as strong as I thought it was. That said,
my preference would still be to provide module-info.class files.
Mark
