Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] [External] : Re: module-info tests

A new Maven repo is not needed to have. You can cut a new Alpha and Beta release versions or use Maven classifier in the name of Maven artifacts for the API jar.

Regarding the testing the Jpms descriptors, can we use a reference implementation? In the EE it was Glassfish.


Dňa st 20. 10. 2021, 1:23 David Blevins <dblevins@xxxxxxxxxxxxx> napísal(a):
> 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.



jakartaee-platform-dev mailing list
To unsubscribe from this list, visit

Back to the top