It already is under "6.1.3. Optional Jakarta Technologies" of the platform specification. Werner Yes, Scott. This is what I proposed for clarification and it should be documented somewhere. For an optional spec to be included there should be commitment from at least one sponsor to provide a compatible implementation. If no one is able to do that, the spec should be removed. In your example, EE 10 should remove B. A Compatible Implementation must fully implement all non-optional elements of a Specification Version, must not extend the API (no supersetting), and must fulfill all the requirements of the corresponding TCK. A Specification Version must identify one or more Compatible Implementations under an Open Source License that, in aggregate, implement all optional elements of the Specification and fulfill the requirements of all elements (including optional elements) of the TCK.
I have a minor question about the modification. Let's look at this scenario: Say we have optional features A, B, C In Jakarta EE9, Open Liberty implements A and B. TomEE implements C. In Jakarta EE 10, Open Liberty decides not to support B any more and no other runtime supports B. Should we remove B from the platform Spec? I don't think this is a valid reason to hold off the release because in aggregation we can't cover all optional elements. This is pretty much a natural route from optional to removal. If we are in agreement, should this be documented somewhere?
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
--
Thanks Emily |