Steve said that, and Looking at the TCK with packages like "com.sun.ts.tests" just now, I really think we have many more issues to solve there than worrying about the EFSP ;-D
I believe both or all 3 are necessary because the spec is too fuzzy about inclusion (that was done in the JCP document quite extensively, but neither the EFSP nor the JESP has an equivalent) and silent about rules for the removal of a spec from the platform or turning it into standalone again.
Personally, I think we should do this exercise to update the EFSP. In the past, the rules were defined based on the best knowledge. Now, we use Jakarta EE releases to test the rules. There should be a straightforward process for the feedback to be considered and the rules updated. I would vote for updating the Compatible Implementations not to force one Compatible implementation to implement all of the optional features. Having said that, I think Jakarta EE9 is unaffected by this exercise as Glassfish does implement all of the optional features. Right?
Yes, the JESP is approved by the Jakarta EE WG. But the JESP specializes the EFSP, it cannot contradict the EFSP on something as fundamental as the definition of Compatible Implementation.
On 2020-07-06 12:35 p.m., Scott Stark wrote:
But the EFSP is extended by the JESP. Cannot the JESP be updated without board involvement?
On 2020-07-02 7:05 p.m., Ed Bratt wrote:
I'd use 'requirements' instead of 'non-optional elements' but that's just me.
Since this is a language alteration to the EFSP, we'll eventually need to move this to the Spec. committee and then, I think we'll need some discussion at an even broader level.
The EFSP is now controlled by the Eclipse Foundation Board of Directors. A super-majority vote of the Board is required to change it. This puts it on par with the Eclipse Development Process.
There are also now multiple groups using the EFSP (Sparkplug, and soon AsciiDoc). They are certainly smaller and less complex than Jakarta EE, but their interests need to be respected when making any modifications.
Just wanted to make it clear that modifying the EFSP is now a more complex task than it was back in 2018 when it was being primarily formulated for the Jakarta EE Working Group.
jakartaee-platform-dev mailing list
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev