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

Maybe I still don't understand your question...

CompanyA is using CXF in their product.  Is CXF a Compatible Implementation of JAX-RS?  Is it a Specification Implementation of JAX-RS (that is, a Compatible Implementation that's open source)?

I was assuming CXF was a Specification Implementation of JAX-RS, just like Jersey, and thus CompanyA's product that includes CXF could be used as a Specification Implementation of the platform.

There is no Reference Implementation of JAX-RS, thus Jersey has no special role, and there's no reason to require or expect that it be used in a Specification Implementation of the platform.


Dmitry Kornilov wrote on 06/21/2018 03:16 PM:


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

A platform implementation needs to be composed of Compatible Implementations, not Specification Implementations.  Unless of course the platform implementation is proposed as a Specification Implementation for the platform specification.  (The difference between Compatible Implementation and Specification Implementation is only that the latter must use an open source license.)

So, I believe the answer to your #1 below is "no”.

Sorry, I was not fully correct with my question. I asked about the Specification implementation of the platform specification, which is required for the platform release. So, the answer to #1 is “yes”. If so, #2 is still open. Who has a business interest in its development?


Dmitry Kornilov wrote on 06/21/2018 02:52 PM:
It makes sense, Richard. But there are still questions:

1. Is platform implementation should be composed from spec implementations only? For example, Jersey is a spec implementation of JAX-RS, CompanyA is using CXF in their product. Does it mean that CompanyA product cannot be used as the platform implementation?

2. Assuming that #1 is true. Who has a business interest investing into this kind of the platform implementation development?

On 21 Jun 2018, at 23:38, Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx> wrote:

I understand where Dmitry is coming from, but having at least one implementation be final before a spec if final has benefits.  I'm not saying a RI, as before, but an SI as new defined as any implementation that is the first to pass the TCKs.  The advantages are:

1. Marketing: When a spec is announced as final there is at least one implementation that people can play with rather than months going by without any implementation.

2. Perception:  If at least one impl is ready when the spec is finalized there is a stronger appearance of continuity and progress.

3. Quality: You really don't know if a specification is implementable until it's implemented by at least one provider.

On Thu, Jun 21, 2018 at 4:30 PM, Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx> wrote:


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@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



Back to the top