search

jakartaee / rest

Jakarta RESTful Web Services
Other
363 stars 119 forks source link

Compatibility certification request for EE4J implementation of Jakarta RESTful Web Services #789

Closed jansupol closed 5 years ago

jansupol commented 5 years ago

Tests results:

 [javatest.batch] Completed running 2663 tests.
 [javatest.batch] Number of Tests Passed      = 2663
 [javatest.batch] Number of Tests Failed      = 0
 [javatest.batch] Number of Tests with Errors = 0
jansupol commented 5 years ago

(Influenced by JavaMail example) This should be referenced from specification project

mkarg commented 5 years ago

What actually do you want the committers of JAX-RS to do with this issue?

jansupol commented 5 years ago

What actually do you want the committers of JAX-RS to do with this issue?

This is a request for the implementation to run the TCK with the API. The reason why this is an issue in the JAX-RS and not at the implementation is not quite clear to me. Maybe it could have been grabbed by any implementation, or maybe it is for the JAX-RS project to have the certification process covered on its own issue tracker. I take it as a document that is filled for the release review.

So I need some committer of JAX-RS to run the TCK. I assume that someone would be me.

mkarg commented 5 years ago

@jansupol I share your point of view. ;-)

starksm64 commented 5 years ago

That is outlined in the https://github.com/jakartaee/specification-committee/blob/master/process.adoc document. The specification project members are responsible for vetting the validity of the certification request. See the Certification Resolution section of that Jakarta EE TCK Process 1.0 document.

spericas commented 5 years ago

+1

mkarg commented 5 years ago

@jansupol @spericas I wonder if this request can be processed due to formal reasons: Neither JAX-RS 2.1.6 nor the TCK is officially released. So how can we certify compliance?

bshannon commented 5 years ago

This looks good, although the TCK results summary needs to duplicate all the information from this certification request. Usually we've just been copying and pasting the content to the top of the TCK results page. See for example the Jakarta Mail TCK results page.

arjantijms commented 5 years ago

+1

chkal commented 5 years ago

+1

asoldano commented 5 years ago

+1

m0mus commented 5 years ago

+1

Tomas-Kraus commented 5 years ago

+1

jansupol commented 5 years ago

I wonder if this request can be processed due to formal reasons: Neither JAX-RS 2.1.6 nor the TCK is officially released. So how can we certify compliance?

We have the API in staging, we have the TCK available in Eclipse download page. Once this is approved and the API is released then everybody will see the API and the TCK that is used to test the compliance. The process is just being created and is new to me as well, if you can see any flaws in the process there is the Specification committee and Steering committee to give the most relevant answers.

mkarg commented 5 years ago

@jansupol The process is new to all of us, includung me. I just wonder why we do not simply release 2.1.6, and vote on the request after that. It seems just more logical to me. I doubt that the spec committee will answer that, as the solve idea of staging is not mandated in any EF process description AFAIK. In fact I wonder who exactly decided about the staging of 2.1.6 at all. Could not remember that the committers decided that.

kwsutter commented 5 years ago

@jansupol Could you please update the TCK link on this CR and the TCK-Results page to point at the official location of the TCK? https://download.eclipse.org/jakartaee/restful-ws/2.1/?d. Thanks!

mkarg commented 5 years ago

@kwsutter There is an official location for the Jakarta REST TCK? What is our technical way to push our binaries there? Maybe it's just me, but I cannot remember that the Jakarta REST committers had been officially informed about that official location. Can someone please point me to that information, seems I missed that.

bshannon commented 5 years ago

Yes, there's an official location where Eclipse will publish the approved and digitally signed versions of the TCKs that can be used for making claims of compatibility. I don't remember all the places we've described this, but it's in the spec review checklist and mentioned with less detail in the TCK process document. Once the spec is approved, a member of the spec committee will copy the TCK from the URL included in the spec Pull Request to the official download location and sign it. It's this official download location that will be included in the web pages describing the approved spec.

mkarg commented 5 years ago

Uhm... what is a "Spec Pull Request"?

spericas commented 5 years ago

@mkarg https://github.com/jakartaee/specifications/pull/7

jansupol commented 5 years ago

Approved by Lazy Consensus and can be closed.

edbratt commented 5 years ago

Revised the d/l link to point at final TCK URL.