|Re: [jakartaee-platform-dev] How should Platform SPEC level requirements be covered by new (SPEC API) TCKs?|
Sending again with a few typos fixed.
There really wasn't enough time in the Platform call on Tuesday to discuss the possibility of having SPEC API level TCKs and how the Platform SPEC requirements would be covered. We have already had some discussion just not on this mailing list yet. I would like to answer how we will identify the Platform SPEC level requirements that SPEC API level TCKs must meet.
More details from past discussions over the past few years:
From April 2019, we have jakartaee-tck/issues/51 `Turning
Platform TCK into a multi-dependency Maven project` . The follow up discussion is on the
Platform TCK mailing list . Of note is Bill Shannon's
response  about which tests should remain in the Platform TCK
(CTS) and which tests should move to the SPEC API project.
This was the first Platform TCK mailing discussion thread that
we had regarding .
More recently, jaxrs-api/issues/924
was opened to answer `TCK:
Extend existing TCK or start our own one?`  which has a cross
blend of different opinions, they started adding tests already.
Other SPEC API projects have also added tests (e.g. see jsonp
tck folder ) or are looking to discuss how they will soon add
Of note are a few Servlet TCK
conversations  started in Sept 2020 on the servlet-dev ml and
continued on the spec-project-leads ml  in Oct 2020. Also
Faces  has a discussion started as well.
The Batch SPEC API team opened
Platform TCK issues/574  to start maintaining the Batch tests
via the Batch SPEC API project instead of the Platform TCK
project. They referenced the  conversation about using
Arquillian in the Batch TCK.
IMO, regardless of how we decide to
maintain the internals of the various TCKs, it would be good to
identify what exactly the Platform SPEC requirements are now and
in the future that at a minimum are required as requested by
Back to the top