[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakartaee-platform-dev] : Re: module-info tests
|
That sounds fine. We have been very clear in every discussion of module-info that there is no requirement for supporting JPMS in container runtimes. I have added this EE10 release note item to have them explicitly callout that lack of standardization around JPMS:
Whatever language we come up with in this effort should make its way into that section/note and common profile/platform sections as well.
Where we need to come to agreement is to never use the word "standard" or "spec defined" when referring to these module-infos.
Key phrases you used that I'd object to include "spec will define what its module-info should" and "the standard module assembly."
A standard where anyone can follow any rules they like, including doing nothing at all, and there is no portability is not how I've traditionally used the word standard. I have concerns about how the platform might evolve if we begin stretching the definition of "standard" or "spec defined" in this way.
We've also outlawed optional features, so the concept that something is spec defined but doesn't need to be followed is not currently allowed.
For me to feel comfortable with us moving in this direction we'd all need to be on the same page (and document) that the module-infos are being provided for convenience, are not standard and may change, do not guarantee portability and are not a feature of Jakarta EE 10 or any Jakarta EE specification.
Even with that universal agreement and documentation, I'm confident many in the world will still misinterpret these module-infos as standard and criticize others like ourselves for being "non-standard." Â I'm willing to take that hit as long as we here are all 100% on the same page that these module-infos are in no way standard or spec defined and are willing to talk through that with people who might interpret them otherwise. Â If we can't agree on that, then adding these module-infos to our jars feels like a bad idea.
In the interest of moving forward, I'd be happy to draft up something (enhance Scott's wikipage) with this understanding so we can all vote on it. When we get that criticism I'll have the text and the vote to point people towards.
Does this sound like a workable path forward?
-David
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
Â
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxxTo unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
