Aggregating external TCK tests

[KyleAure]

Is your feature request related to a problem? Please describe.
The Jakarta concurrency community has agreed that porting the concurrency TCK to be hosted in the https://github.com/eclipse-ee4j/concurrency-api repository is a worthwhile venture to modernize the development of the concurrency specification. An issue has been opened under: jakartaee/concurrency#145

Describe the solution you'd like
I would like to revisit the solution proposed by Andy under PR: #154
To aggregate the TCKs developed in their specification repositories back into the jakartaee-tck project.
This will help prevent developers from having to back port their natively hosted TCKs back to this project.

Describe alternatives you've considered
Another alternative (that I don't expect to the a popular choice) would be to ONLY host the TCK in the spec repository and remove it completely from this repository.

Additional context
None

[scottmarlow]

Hi @KyleAure

Is your feature request related to a problem? Please describe. The Jakarta concurrency community has agreed that porting the concurrency TCK to be hosted in the https://github.com/eclipse-ee4j/concurrency-api repository is a worthwhile venture to modernize the development of the concurrency specification. An issue has been opened under: eclipse-ee4j/concurrency-api#145

👍

Describe the solution you'd like I would like to revisit the solution proposed by Andy under PR: #154 To aggregate the TCKs developed in their specification repositories back into the jakartaee-tck project.

For Concurrency, the current Platform requirement validation is performed with (Java Test Harness) TCK vehicles for ejb servlet jsp (as per https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/install/jakartaee/other/vehicle.properties#L55).

With the Concurrency TCK, will the Platform TCK need a way to provide additional Arquillian/Shrinkwrap classes for deployment of ejb, servlet, jsp tests? I assume the Concurrency TCK will not include ejb, servlet, jsp tests, correct?

This will help prevent developers from having to back port their natively hosted TCKs back to this project.

We started refactoring the Platform TCK last summer to switch to Maven, Arquillian/Shrinkwrap but didn't get far enough for EE 10. After EE 10 is final, we will resume the refactoring work (after syncing up with all of the EE 10 changes :-)

If you target EE 10 with the changes, possible options for testing Concurrency for the Jakarta EE Platform could be:

1. Run some/all of existing (EE 9.1) Platform TCK tests to verify Concurrency API can be used with EJB, Servlet, JSP.
2. Bring the Concurrency TCK artifact into Platform TCK for running tests with EJB, Servlet, JSP in some way.

We don't have a prototype of doing #2 yet, it is likely that we will try that for one of the specification TCKs and likely try to reuse for others. This Platform TCK work may happen after the Concurrency SPEC is released, which means no more changes would be expected to the Concurrency TCK.

The #1 solution would be likely to be used if no better way is introduced in time for the EE 10 release.

Describe alternatives you've considered Another alternative (that I don't expect to the a popular choice) would be to ONLY host the TCK in the spec repository and remove it completely from this repository.

We do want to remove TCK tests from this repository but only after making other changes that still validates the https://jakarta.ee/specifications/platform/9.1/jakarta-platform-spec-9.1.html#concurrency-2-0-concurrency-utilities-requirements requirements for Jakarta EE implementations.

[KyleAure]

Hello @scottmarlow thanks for the reply.

With the Concurrency TCK, will the Platform TCK need a way to provide additional Arquillian/Shrinkwrap classes for deployment of ejb, servlet, jsp tests? I assume the Concurrency TCK will not include ejb, servlet, jsp tests, correct?

This is the point I am at currently with refactoring the concurrency TCK tests.
I want to find a way for the concurrency TCK test to be able to run the ejb, servlet, and jsp tests as they do today. I just haven't figured out what the solution looks like yet.

[scottmarlow]

Hello @scottmarlow thanks for the reply.

With the Concurrency TCK, will the Platform TCK need a way to provide additional Arquillian/Shrinkwrap classes for deployment of ejb, servlet, jsp tests? I assume the Concurrency TCK will not include ejb, servlet, jsp tests, correct?

This is the point I am at currently with refactoring the concurrency TCK tests. I want to find a way for the concurrency TCK test to be able to run the ejb, servlet, and jsp tests as they do today. I just haven't figured out what the solution looks like yet.

Would it be easier for you to create a maven project in the Platform TCK that runs those concurrency tests on ejb, servlet, jsp using the concurrency TCK artifact as a base?

[scottmarlow]

#154 does look like a good idea!

[scottmarlow]

I'm removing the EE10 label as we are out of time to address this issue for EE 10. I think it makes sense to complete after EE 10.