Re: [jakarta.ee-spec.committee] Implementations requirements

[Bill Shannon <bill.shannon@xxxxxxxxxx>]

Just to clarify...

Dmitry is expressing his personal view here.  It remains Oracle's view
that an implementation (and a TCK) is absolutely required before a
specification is approved.


Dmitry raises some other points here that are worth discussing further.
In particular, whether we really want a "platform" and corresponding
implementation going forward.

Also, Oracle has a TCK challenge process that we've used for many years,
and that many of you have some experience with.  Should we adapt and
standardize that process for Jakarta EE, and if so how we can improve it?


Dmitry Kornilov wrote on 06/19/18 07:51 AM:
> Hi,
> 
> I met some spec committee members on EclipseCon France and discussed my concerns about the spec process. I am starting this thread to discuss it with wider audience.
> 
> Here are my suggestions:
> 
> 1. To achieve yearly platform release cadence we should get rid of the platform implementation and make specs implementations optional. 
> 
> Developing an implementation requires time and resources. Many projects implementations were maintained by Oracle and it’s an open question who will support them after moving to EE4J. It can become a platform release blocker. 
> 
> Another uncertainty is the platform implementation. It’s questionable that GlassFish will stay as Jakarta EE spec implementation. It’s used by Payara and Fujitsu. Other vendors are not interesting in it. Will Payara and Fujitsu be able to support and maintain it? As it is now the platform cannot be released without one implementation passing all TCK tests. It may also become a release blocker.
> 
> Another (different from GlassFish) platform implementation may replace GlassFish. It can be Open Liberty, for example. In this case one vendor takes the dominant leader position (IBM in Open Liberty case) which may not be accepted well by the community. 
> 
> Solution to this problem is removing the implementation requirement from the spec process. The spec implementations become 'nice to have' instead of 'must have’. During the spec review process the spec committee (or the platform project) decides if implementation required or not. The decision should be made based on risks analysis and agreements from vendors to implement it in future. The platform implementation also becomes optional. Vendors will release their implementations after the platform API is released.
> 
> If not requiring spec implementations sounds too strong we can agree to get rid of the platform implementation only.
> 
> The disadvantage of this plan is that without the implementation, it’s not guaranteed that the spec is implementable. To address it we should have a well defined process of specs and TCKs modifications.
> 
> 2. TCK challenges support plan
> 
> Because the implementation can be developed after the API release, the spec process must guarantee that TCK challenges are solved as quick as possible. It must specify the response times from spec project teams. Also, the spec process has to define what is done if challenge is accepted and new version of TCK and possibly the spec needs to be released.
> 
> Please make your comments.
> 
> Thanks,
> Dmitry
> _______________________________________________
> jakarta.ee-spec.committee mailing list
> jakarta.ee-spec.committee@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
>