TCK Challenge Tests with Duplicated Classes

[aubi]

Specification:

Jakarta Concurrency 3.0.0

Challenged test(s):

ee.jakarta.tck.concurrent.spec.ManagedExecutorService.security.SecurityTests#managedExecutorServiceAPISecurityTest

ee.jakarta.tck.concurrent.spec.ManagedExecutorService.security.SecurityTests#managedScheduledExecutorServiceAPISecurityTest

TCK version:

3.0.0

Tested implementation:

Payara 6 (branch) with Concurrent-RI (branch)

Description

The test have classes SecurityTestRemote and SecurityTestEjb in both jar and war in the same ear, causing deployment issues.

Fixes are available: #218, #221

[scottmarlow]

As per TCK Process challenges can take up to 10 days to determine if they should be accepted or denied, so 5 more days left. Having said that, the challenge could be addressed before 10 days.

Also worth quoting what happens if consensus is not reached:
Challenges can be resolved by a specification project lead, or a project challenge triage team, after a consensus of the specification project committers is reached or attempts to gain consensus fails. Specification projects may exercise lazy consensus, voting or any practice that follows the principles of [Eclipse Foundation Development Process](https://www.eclipse.org/projects/dev_process/).

If the challenge is accepted then the challenged test(s) can be excluded and released via a new TCK.

[scottmarlow]

From discussion in referenced #218 + #221 issues, it sounds like we have identified the test correction.

Also of reference is jakartaee/batch-tck#49 (comment) which discusses how we could make a test change if the Concurrency team thinks the change is safe (e.g. passes any compatible implementations that are possible to run, passing Open Liberty would be enough but other implementation following this conversation could also run independently). If we later discover via subsequent TCK challenges that said safe change was not actually a valid change, the likely approach is to exclude the test and resume updating the test for the next Concurrency major/minor release.

[aubi]

I'm convinced, that the fixes are safe, break nothing and could be added to the next version of TCK.

[smillidge]

I've accepted the challenge and will disable the test in the 3.0.1 service release of the TCK