Standard Rules while separating standalone TCKs from platform TCK

The wiki attempts to create some general rules and common steps that can be refered while separating standalone TCKs out from the platform TCK repository and to convert them into JUnit/maven based tests.

1. It is required to decide whether server like environment or container based testing is required for the standalone TCK. and whether archives need to be deployed to the container for testing. Arquillian is the currently accepted way for creating and deploying archives using shrinkwrap api.

• The initial POC PR that was used for Jakarta REST TCK migration https://github.com/jakartaee/rest/pull/1002 , wiki https://github.com/alwin-joseph/rest/wiki/REST-TCK-separation-from-JakartaEE-TCK-repo describes the migration effort.
• If no containers are required for testing, the JSONB TCK example can be followed. PR https://github.com/eclipse-ee4j/jsonb-api/pull/276/.

2. The tests in platform repository runs in different vehicles based on the property file install/<tck>/other/vehicle.properties for . The standalone tests need to adhere to the specification requirements on running in these vehicles while migrating the tests. For instance jaxrs tck was run run in servlet vehicle, the arquillian uses servlet container hence the migration of tests did not require additional changes to run them in servlet vehicles.

3. install/<tck>/bin/build.xml is the main ant file specific to each technology for building the tck from jakartaee-tck repository. The java source files in list all.test.dir can be considered as the list of files with the tests. Also each test method would have @testName tag in the comments, for JUnit these methods will need @org.junit.jupiter.api.Test tag.

4. Need to implement the list of tests run for javaee full platform , webprofile, standalone and other profile runs as specified in src/com/sun/ts/lib/harness/keyword.properties . org.junit.jupiter.api.Tag can be used to implement the special keywords to create test groups. The install/<tck>/bin/ts.jtx has the list of tests disabled, the same can be implemented using @org.junit.jupiter.api.Disabled Tag in Junit

5. release/tools/<tck>.xml will have the list of files that is included in the legacy final tck bundle. Chose those java/class files and the other helper files from here for the migrated tests so those will be included in the bundle post migration.

6. jakartaee-tck/lib/ has the jars used for build/run of the tcks. The same can be mentioned as dependency in maven project after migration instead of using jars from repository. The current legacy standalone TCK bundle will have the jars that is required for the tck to be run. For eg : in Jakarta REST common-httpclient was used to build and run the tck hence used it as maven dependency in tck build pom https://github.com/jakartaee/rest/blob/6f453f85ed8aa5b1ae4b8261b9039d28cd974b04/jaxrs-tck/pom.xml#L190 and run pom https://github.com/jakartaee/rest/blob/master/jersey-tck/pom.xml

7. userguides are present at jakartaee-tck/user_guides/ : The current users guides in jakartaee-tck project are maven projects. They can be moved directly to a new repo/maven-project. It would be required to edit the userguide contents for change in details related to migration of the tck.

8. Create tck runners for implementations: One the standalone TCK is created as jar or archive bundle it is recommended to execute against atleast one implementation. The https://github.com/eclipse-ee4j/jakartaee-tck/tree/master/glassfish-runner has some tck runners against glassfish server.