> On Apr 13, 2022, at 7:00 AM, Scott Marlow <
smarlow@xxxxxxxxxx> wrote:
>
>
> On 4/13/22 8:51 AM, Thomas Watson wrote:
>> I agree with David on both points. We should be pragmatic to get the EE 10 released and work towards solving the TCK problem in a future specification release. The most important thing is to agree what the requirements are for running the individual TCKs
within the platform/profile for which the specifications are included. Then we can work towards solving the requirements.
> The TCK process currently states:
> "
> 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.
> "
>
> As per ^, the JSON-P/JSON-B SPEC team is responsible for the JSON-P/JSON-B TCK tests, as the SPEC API team is responsible for maintaining the TCK tests.
I agree with all the very pragmatic statements you made in your email. Specifically about resourcing, being at limits, needing volunteers and the impact TCKs have on a specification project's ability to thrive. Extremely critical stuff.
I do want to flag up that if a Platform/Profile includes a specification, it is that Platform/Profile's responsibility to define the testing requirements they think are necessary. So while I agree having discussion happen in individual specification projects,
we should continue the broader conversation here.
Regardless of what individual specification projects decide, we're still on the hook for the TCK requirements we define. If an individual specification decides they are an SE-focused spec that can run outside a container and create a TCK for that, that's great.
When we create the requirement that it can work inside a Platform/Profile, we're on the hook for deciding and delivering on those testing requirements.
In practical terms, this may mean that if some specification projects are producing and shipping junit tests (for example), and we decide we want those tests to be runnable in a container, we create our own in-container JUnit runner similar to how IDE's have
their own JUnit runner and Maven and Gradle have their JUnit runner.
But again, we first decide our goals. Then we look at the resources. Then we have some pragmatic discussions on what we can achieve.
-David
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!dxjKN5ceunw25v9xzw7TA6migCQnufuhcSGCfhdB_xx8hgiu6idMP0Wp07BtvqYPEJg$
