I am not sure I understand the point here.
Each Jakarta EE spec will define what its module-info should be and the API jar from the spec project will contain that module-info.class file.
Since the module-info specific to the module in which it is contained, depending upon how people choose to assemble the API packages into modules means there can be a different module-info for each such assembly. The Jakarta EE specs will define the module-info for the standard module assembly (API jar) made by the project. Others who define alternate assemblies of API packages (e.g. uber-jars of APIs) will then need to define, if desired, a module-info specific to that assembly.
Projects which independently implement the APIs but produce an otherwise identical assembly (exactly the same packages) as the spec project's API jar, can provide the spec defined module-info class as both modules are thus completely interchangeable.
But if the assembly contains other packages or has different needs (like connecting to specific implementation modules), then that assembly is not a module which is interchangeable with the spec project's API jar and would this need a different module-info.
But I don't see any need for Jakarta EE or EE4J to maintain a catalog of all the possible module-infos of these other assemblies.
--
BJ Hargrave
Senior Technical Staff Member, IBM // office: +1 386 848 1781
OSGi Fellow and OSGi Specification Project lead // mobile: +1 386 848 3788
hargrave@xxxxxxxxxx
----- Original message -----
From: "David Blevins" <dblevins@xxxxxxxxxxxxx>
Sent by: "jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
To: "jakartaee-platform developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx>
Cc:
Subject: Re: [jakartaee-platform-dev] [External] : Re: module-info tests
Date: Tue, Oct 19, 2021 19:23
> On Oct 19, 2021, at 3:54 PM, Scott Stark <starksm64@xxxxxxxxx> wrote:
>
> That there were clients of subsets of the API jars asking for the ability to combine the spec jars with their JMPS aware runtimes, and the existing automatic module names did not work with tools like jlink.
What do people think about simply creating a non-spec repo to add the non-standard module-infos to the desired API jars and then push them back to Maven Central somewhere under a 'org.eclipse.ee4j' groupId?
Some benefits I see:
- Would give those who want to support JPMS a way to do that freely, without restriction, or delay
- Enables some real-world JPMS usage/evolution that is understood to be non-standard
- We here are then completely free to some day spec out standard module-infos without backward compatibility concerns from prior non-standard attempts
- Doesn't create a scenario where others who produce equivalent API jars are told "yours is not compliant"
- Avoids us creating a perception/precedent that it is ok to add non-standard items to specifications, which is worse than optional IMO
- Avoids us stretching the definition of what can/should be done under a service release
We could add a repo to an existing non-spec EE4J project, or we could create a new non-spec EE4J project, or we could just stand up a new github repo outside Eclipse. There'd be one repo with 30-ish modules and the right bits in a parent pom to make doing it fairly straight forward.
Basically, let's do it, just not under the Jakarta brand. The EE4J brand is perhaps the more appropriate to collaborate on not-yet standard features.
Thoughts?
-David
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
