I thought so, but it will be interesting to see how the two other mentioned users of the EFSP use that because both SparkPlug and Asciidoc are more protocol definitions and not API centric. Especially Asciidoc describes itself as a text document format, so it’s like JSON or XML and has no similarity with e.g. the JAXB, JSONB or JSONP specs under Jakarta EE.
Some of these definitions were pretty much carbon-copied from the Java EE stack and JCP and now we see other standards use them that have more in common with those defined at OASIS or W3C than the JCP or Jakarta specs.
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.
+1.613.220.3223 (m)
