search

jakartaee / rest

Jakarta RESTful Web Services
Other
362 stars 117 forks source link

TCK Migration : Userguide & assertions #1059

Closed alwin-joseph closed 2 years ago

alwin-joseph commented 2 years ago

Issue https://github.com/eclipse-ee4j/jaxrs-api/issues/1040

To build the userguide : 

cd jaxrs-tck-docs/userguide
mvn
jansupol commented 2 years ago

The assertion lists are great, but we would need the ones in xml format, too.

Should we add the new module to the pom.xml?

alwin-joseph commented 2 years ago

The assertion lists are great, but we would need the ones in xml format, too.

I have added the xml files too. Both xml & html were updated manually for Jaxrs 3.0 release as it exists in the jakartaee-tck repository.

Should we add the new module to the pom.xml?

The tck userguide can be built using mvn from jaxrs-tck-docs/userguide folder and the same can be added as module to parent pom if necessary. That would cause tck userguide to be built everytime the maven build starts from parent pom, eventhough tck userguide module does not depend on other modules. If that is ok, I can add jaxrs-tck-docs/userguide module to pom.xml.

spericas commented 2 years ago

@alwin-joseph Why can't we set the version to be 3.1 as part of this migration process?

alwin-joseph commented 2 years ago

@alwin-joseph Why can't we set the version to be 3.1 as part of this migration process?

I will update the Release notes with 3.1. Can the spec team help update spec/api assertions.

jansupol commented 2 years ago

The new assertions in the javadoc assertion list are great, but the assertion list does contain some oddities. For instance: JAXRS:JAVADOC:1__OLD and JAXRS:JAVADOC:1. These are basically the same, with a minor change in javadoc wording. Possibly, the XML should be updated to contain only one (the new wording) and the OLD wording is not included. The same with all other OLD assertion IDs.

The Spec Assertion list newly contains JAX-RS:SPEC assertions, whereas the old list contains JAXRS:SPEC assertions. The tests contain the old JAXRS:SPEC notion. Should we need test coverage, the test coverage tool matches the assertion ids.

jansupol commented 2 years ago

The documentation PDF is nicely generated, that's cool. However, the result of the maven execution is not a maven artifact that can be staged into the maven repository. Possibly, a bundle task or module would be needed. I am not sure whether as a part of this PR or a separate PR. Personally, I'd love to see it being a part of the TCK bundle rather than a separate maven artifact. What do people think?

alwin-joseph commented 2 years ago

The documentation PDF is nicely generated, that's cool. However, the result of the maven execution is not a maven artifact that can be staged into the maven repository. Possibly, a bundle task or module would be needed. I am not sure whether as a part of this PR or a separate PR. Personally, I'd love to see it being a part of the TCK bundle rather than a separate maven artifact. What do people think?

  1. The Ballot spec PR expects the TCK as a zip bundle of the format jakarta-restful-ws-tck-x.y.z.zip as it was done for previous releases.
  2. What we can do is to generate the zip TCK bundle that contains the TCK jar jakarta.ws.rs-tck-x.y.z.jar and a documentation folder (that contains userguide, assertions etc ). This can be done as a part of the CI job https://ci.eclipse.org/jakartaee-tck/job/jakarta-rest-tck-build/ which currently adds only the TCK jar within the zip (https://ci.eclipse.org/jakartaee-tck/job/jakarta-rest-tck-build/lastSuccessfulBuild/artifact/jaxrs-tck/target/jakarta.ws.rs-tck-3.1.0.zip).

Would that suffice?

spericas commented 2 years ago

The documentation PDF is nicely generated, that's cool. However, the result of the maven execution is not a maven artifact that can be staged into the maven repository. Possibly, a bundle task or module would be needed. I am not sure whether as a part of this PR or a separate PR. Personally, I'd love to see it being a part of the TCK bundle rather than a separate maven artifact. What do people think?

  1. The Ballot spec PR expects the TCK as a zip bundle of the format jakarta-restful-ws-tck-x.y.z.zip as it was done for previous releases.
  2. What we can do is to generate the zip TCK bundle that contains the TCK jar jakarta.ws.rs-tck-x.y.z.jar and a documentation folder (that contains userguide, assertions etc ). This can be done as a part of the CI job https://ci.eclipse.org/jakartaee-tck/job/jakarta-rest-tck-build/ which currently adds only the TCK jar within the zip (https://ci.eclipse.org/jakartaee-tck/job/jakarta-rest-tck-build/lastSuccessfulBuild/artifact/jaxrs-tck/target/jakarta.ws.rs-tck-3.1.0.zip).

Would that suffice?

AFAIK, yes, that would be sufficient.

edbratt commented 2 years ago

FWIW, I've posed a question to the Spec. Committee, asking if we can relax the submission requirements and allow EITHER .zip or .jar file names for the final TCK archive. Continue working toward creating a .zip for now, but if the committee will allow it, I think it will be better in the long run to allow .jar since it can be used more readily by the intended TCK users.

alwin-joseph commented 2 years ago

The new assertions in the javadoc assertion list are great, but the assertion list does contain some oddities. For instance: JAXRS:JAVADOC:1__OLD and JAXRS:JAVADOC:1. These are basically the same, with a minor change in javadoc wording. Possibly, the XML should be updated to contain only one (the new wording) and the OLD wording is not included. The same with all other OLD assertion IDs.

Removed the *__OLD javadocs from both xml & html javadoc assertion files in 3.1.0

The Spec Assertion list newly contains JAX-RS:SPEC assertions, whereas the old list contains JAXRS:SPEC assertions. The tests contain the old JAXRS:SPEC notion. Should we need test coverage, the test coverage tool matches the assertion ids.

JAX-RS:SPEC is renamed to JAXRS:SPEC for spec assertion files in 3.1.0