Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec.committee] Specification Committee call agenda, October 3/2018

My apologies if I came across a bit frustrated today. My Internet connection was flaky all morning, making it very challenging to participate in the discussion.

Here's what I took away from our call...

We agreed that at some point it will be desirable to refactor the EE4J project to create a Top Level Project specifically for Specification Projects related to Jakarta EE.

Note that the EFSP itself is not concerned with how projects are organized. A Working Group can claim Specification Projects hosted under any of our Top Level Projects. A Specification Committee may choose to require that the projects under their umbrella host in a particular Top Level project, but there is no general requirement to do so. This may become an FAQ entry.

We discussed the nature of the meaning of a Specification Committee vote. This discussion was started by my assertion that a Specification Committee owned the overall "vision" for how the various Specification Projects hang together. My best summary  of the discussion is that the Specification Process is silent on the matter and that individual committee members determine their own criteria for voting (at a minimum, with each vote committee members need to agree that the Specification Project followed the process).

We decided that defining "Platform" serves a marketing need and should be left in.

The terminology around "fulfills all requirements" was deemed to be sufficient.

Discussion did highlight that the TCK is more than just code. It must include documentation which may describe other requirements. We discussed that it is the Specification Committee's responsibility to set requirements for the structure and content of a TCK.

We ran out of time before we could get to the following. Let's continue the discussion tomorrow.


Are these statements sufficient?

A Compatible Implementation must fully implement all non-optional elements of a Specification Version, must not not extend the API (no supersetting), and must fulfill all requirements of the corresponding TCK. 

Is it sufficient to require that just one Compatible Implement fully implement a specification, including all optional elements?

A Specification Version must identify at least one Compatible Implementation under an Open Source License that implements all optional elements of the Specification and fulfills the requirements of all elements (including optional elements) of the TCK.

By way of clarification, when we say that a CI must implement all optional elements, does this apply to the prerequisites? e.g. (hypothetical) if one has to implement all optional elements of the JSP specification; does one have to also implement all optional elements of the servlet specification, or only those optional elements of the servlet specification that the JSP specification requires be implemented? 

The answer to this question, should be an FAQ entry.

Do we need to make it clear that adding a Compatible Implementation to a Final Specification does not change the Final Specification? i.e. no ceremony is required. IMHO, the process by which Compatible Implementations get added is an implementation detail.

Wayne
--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation, Inc.

Meet us at EclipseCon Europe 2018: LUDWIGSBURG, OCTOBER 23 - 25



--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation, Inc.

Meet us at EclipseCon Europe 2018: LUDWIGSBURG, OCTOBER 23 - 25


Back to the top