Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec.committee] Implementations requirements


On 21 Jun 2018, at 22:50, Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:

Yes, by "platform" I meant something similar to the Java EE platform (what some people think of as the "full profile").  Not necessarily everything defined by the Jakarta EE process, but everything we think should be made available in full implementations of the platform.

If there's no interest in defining such a thing going forward (i.e., there will be no "Jakarta EE 8" or "Jakarta EE 9"), then what's the purpose of Eclipse GlassFish?

Jakarta EE (8, 9, … , n) can be only a set of APIs + TCKs. It can be released without any implementation. Implementations are released sometimes later (after the platform release) to not be a blocker of the platform release.

— Dmitry


Richard Monson-Haefel wrote on 06/21/2018 07:08 AM:
If, by platform, you mean the full Java/Jakarta EE stack than I would say, no.  I would prefer that if there is a "platform" that it represents the entire Jakarta EE ecosystem, for which there is no implementation, or that it be confined to a very small set of "core" technologies.  Either way, the set of reference implementations that have been donated by Oracle (e.g. Eclipse, etc.) should be separated as a top-level project from the Jakarta EE Specification Working Group.

On Wed, Jun 20, 2018 at 6:39 PM, Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
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@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
>
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee



_______________________________________________
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

_______________________________________________
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

Back to the top