Initial version of core profile TCK #966
Conversation
Signed-off-by: Scott M Stark <starksm64@gmail.com>
Signed-off-by: Scott M Stark <starksm64@gmail.com>
| @@ -0,0 +1,201 @@ | |||
| Apache License | |||
There was a problem hiding this comment.
fyi for other reviewers, https://blogs.eclipse.org/post/wayne-beaton/eclipse-project-licenses states that Eclipse projects already are using Apache License Version 2.0
| <mkdir dir="${project.build.directory}/tcks"/> | ||
| <!-- download file --> | ||
| <get src="https://download.eclipse.org/jakartaee/jsonp/2.1/jakarta-jsonp-tck-2.1.0.zip" | ||
|
|
There was a problem hiding this comment.
As a user that has installed the core-profile-tck distribution, is it okay if I manually update the installed copy of this file to update to new versions of jsonp-tck (e.g. to use 2.1.1.zip?
There was a problem hiding this comment.
Yes, this is just what matches the current dependencies stated in the TCK. If the component specs release new service releases they can be used. Do we need to say something to that effect?
There was a problem hiding this comment.
Yes, would be good to state that users can manually update their local installed copy of artifacts-pom.xml to reference new service releases (e.g. any new TCK releases in https://download.eclipse.org/jakartaee/jsonp/2.1).
There was a problem hiding this comment.
I created tracking issue #975 for making this change so this pr can be merged.
|
Looks great other than mentioned (minor) feedback. |
Signed-off-by: Scott M Stark <starksm64@gmail.com>
| .withTransitivity() | ||
| .asResolvedArtifact(); | ||
|
|
||
| WebArchive archive = ShrinkWrap.create(WebArchive.class, "jsonp-tck-tests-all.war").as(WebArchive.class); |
There was a problem hiding this comment.
Perhaps I do not understand this well. But the core profile does not support servlet, how come it should support a war archive? Would e.g. Quarkus or Helidon be happy with Arquillian deploying a war?
There was a problem hiding this comment.
On the other hand, Jakarta REST TCK contains mainly wars. But still, no container to deploy to...
There was a problem hiding this comment.
But the core profile does not support servlet
I've always felt we're making our lives more difficult by officially not supporting Servlet, but then practically assuming Servlet anyway.
Maybe we should clearly state why we think we dislike Servlet, and why we need to officially avoid it. Based on that we may want to discuss if a servlet-lite is feasible, which excludes all the things we think we need to avoid.
There was a problem hiding this comment.
We talked a bit about this at the end of the last platform call. We don't have a pure LibraryContainer archive type in Arquillian that can be used, so WebArchive is used as a proxy. We had to do this in CDI Lite as well. This is something that needs to be address going forward.
Restful does not support servlet either, but its TCK is what is bringing in the requirement to use a servlet. One aspect is wanting a lighter servlet api, but the other is allowing for the possibility to use another invocation mechanism. As of now, supporting servlets can be considered a TCK porting package implementation detail. We will need to address this in the future if a compatible implementation challenges this aspect of the TCK.
There was a problem hiding this comment.
Restful does not support servlet either
If you mean Jakarta RESTful Web Services, then the Servlet 2.5 container was the only mandatory environment that needs to be supported by each implementation. That is why the TCK chose to use it. See https://jakarta.ee/specifications/restful-ws/3.1/jakarta-restful-ws-spec-3.1.html#servlet. Since 3.1 there is another possibility for SE Bootstrap, too.
There was a problem hiding this comment.
I think this at least allows the runtimes that support servlet execute the json-p and json-b tests.
There was a problem hiding this comment.
My point was that JSON-P and JSON-B are standalone tests only, they do not need any container to be run. I do not mind this being resolved later, though, if that's an Arquillian issue.
There was a problem hiding this comment.
I think @starksm64 demonstrates how to get them running in a container, which is useful for EE container as a means to execute the tests.
There was a problem hiding this comment.
IMO, we should have consistent approach for JSONP tests running in a container or as a standalone for all of Jakarta EE profiles.
There was a problem hiding this comment.
For EE10 the standalone approach is all that is required. The in container module is just an example for future work or for containers to experiment with.
| <include>jakarta.ee.tck:core-tck-parent</include> | ||
| <include>jakarta.ee.tck:cdi-lite-tck-suite</include> | ||
| <include>jakarta.ee.tck:core-profile-tck-impl</include> | ||
| <include>jakarta.ee.tck:core-tck-jsonp-extension</include> |
There was a problem hiding this comment.
Can we do the same thing for jsonb?
There was a problem hiding this comment.
@Emily-Jiang could you please create a tracking Platform TCK issue for adding a tck-jsonb-extension similar to jakarta.ee.tck:core-tck-jsonp-extension.
core-profile-tck/tck-dist/src/main/asciidoc/tck-reference-guide.asciidoc
Show resolved
Hide resolved
|
Merging later today so we can start building this TCK via CI. Further changes should be made via separate pull requests. |
Describe the change
This is the candidate TCK for the new Jakarta Core Profile.
Additional context
When discussed where this should live on the platform group, we thought it was best to live under the jakartaee-tck project.
CC @alwin-joseph @anajosep @arjantijms @cesarhernandezgt @dblevins @m0mus @edbratt @gurunrao @jansupol @jgallimore @kazumura @kwsutter @LanceAndersen @bhatpmk @RohitKumarJain @shighbar @gthoman @brideck @scottmarlow