TCK environment contains optional tests and dependencies by default

[JanWesterkamp-iJUG]

Describe the bug
The TCK includes optional tests by default, TCK users are required to configure exclusion of them manually. This results in opt-out instead of opt-in behaviour.
Some of these optional TCK tests require a Jakarta Web Profile component spec too, so resulting in expecting an environment beyond Jakarta Core Profile to run these tests (as default) - which violates the current requirements for the MicroProfile umbrella spec.
This component spec Jakarta Concurrent/Concurrency 3.0.3 version deviates by a Patch Release from the current Jakarta Web Profile version (3.0.2) and is configured as compile dependency.

The default setup must not require optional tests.
The default setup must not depend on a non-core-profile Jakarta component spec, as this excludes MiroProfile implementations that are based on the Jakarta Core Profile only.
Managing dependencies separately and not conform with the given environment will result in dependency issues.

(Describe the problem as concisely as possible.)

Potential solutions:

There is not simply way to solve all aspects of this, but optional test definitions and dependencies should be omitted in general.
The dependency tree for umbrella and component specs need to be respected.

Splitting up the TCK into a core (required) and optional module (i.e. like in MP Metrics), may be with a distribution package that can be configured according to the environment, might solve the optional test configuration issue.
Preventing the use of Jakarta Concurrency (introduced in #108) at all or moving that module outside the component spec into a separate stand-alone component spec (not part of the MicroProfile umbrella spec) could allow the usage and dependency to it. BTW, this is a pattern used for the MP JWT integration with Jakarta Web Profile/Platform specs recently (the so - not optimal - called MP JWT Bridge spec).

If we do not respect the existing dependency tree, we will not solve the dependency deviations - so simply using the latest version is not the best way. Even when here the deviation in theory should not have an effect, I could make a difference in practice.
Unfortunately there is no updated version in the Jakarta EE BOM avalilable, as there is no support for a Patch Release on Jakarta EE 10 currently.

[Emily-Jiang]

We discussed this in the past calls. In other MP and Jakarta spec tcks, the same approach was used. To be honest, the optional TCKs are clearly documented and the tck tests are executed by individual implementation and they will have to read the tck doc to have their set up.

[JanWesterkamp-iJUG]

We discussed this in the past calls. In other MP and Jakarta spec tcks, the same approach was used. To be honest, the optional TCKs are clearly documented and the tck tests are executed by individual implementation and they will have to read the tck doc to have their set up.

@Emily-Jiang: Because others do this the wrong way is not a good reason to do it wrong too.
This is an architecture failure and requiring to read the docs and do manual configuration is the opposite of Continuous Integation at all!
I still think this must be fix to if somebody wants to run the optional tests that require an Web Profile implementation or at least addtional Jakarta Conncurency added, this requires manual configuation and may be an requirement, if you are running on a Web Profile+ mplementation instead of an Core Profile only one.

[JanWesterkamp-iJUG]

Now we have our first (valid in my opinion) TCK challenge because of this: #137

We need to discuss this on our next meetings (MP Telemetry call for the specific point and may be MP Technical call for the general ones) - I will add a point to the agenda for MP Telemetry first.

To prevent issues like this by detecting them earlier in the release process it would be very helpful to have a (additional) CI that is a pure Jakarta Core Profile based implmentation (i.e. Helidon, Quarkus) or can be configured to behave like that.

Also having tests to vaildate the architecture automatically (may be implemented with jQAssistant or ArchUnit) could prevent violations like this in the future.