Not at all, because we can introduce the jpms descriptors in the alpha versions. It is something like development release version and anybody can check it out for an interest but nothing serious.
It sounds like people want final and production-ready jars that have non-standard module-infos, so development releases likely wouldn't help them.
If we were intending the module-infos to become standard before a final release, I'd agree completely.
-David
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.
I think that would make sense if the intentions were to standardize and test these module-infos. It doesn't appear that's the goal.
-David
> 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
_______________________________________________
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
|