Re: [jakarta.ee-spec.committee] Requirements for individual specificatio

[David Blevins <dblevins@xxxxxxxxxxxxx>]

> On Apr 7, 2022, at 6:13 AM, Thomas Watson <tjwatson@xxxxxxxxxx> wrote:
> 
> Was this approach agreed upon by the specification committee?  Is that even something the specification committee is responsible for deciding if it is the right approach?  I admit that I may be missing some past context where a tactical decision was made to expediate an EE 10 release.  Perhaps it is the best we can do for EE 10 with the timeline and the number of developers available to improve the situation.

It is within the committee's purview to set any TCK requirements we fell are necessary.  Further, it is within each members right to vote -1 on ballots when they feel it is necessary.

> Instead of focusing on what we can and cannot do for EE 10 I want to circle back to the potential proposal I laid out with this thread.  Is there agreement that we have a gap in the current approach being taken?   Would having requirements in place that I suggest help close the TCK gap to ensure that the EE platform and other profiles compatible implementations do indeed function properly for all aspects of the specification?

I think that's a pragmatic callout that appears to have been missed in the responses I've seen.

Agreeing where we want to go in the long run, while simultaneously agreeing it isn't achievable in the short term has been our status quo for the last 4 years.  I do think it would be wise to continue that practice so we can keep raising the bar long-term.  Having been in your shoes many times I often find I'm far more willing to make short-term allowances as long as we agree with the goal long term and will make steps to achieve it.

I definitely agree to the long term goal of ensuring TCKs that are runnable individually should also be runnable inside the actual Profile or Platform implementation that uses them.  We have frequently found situations where a component implementation passes its TCK, but there are test failures when those tests are run in our assembled server.  It is not the "integration" portions of the tests that typically fail, but often very basic functionality caused by issues such as conflicting META-INF/services file, or not being able to use default implementations of some interfaces/extensions the library has for creating instances or scanning annotations.  They are certainly issues caused by integration, but the functionality lost is often very rudimentary stuff and not at all edge-case features.

That said, we are trying to free ourselves from a monolithic TCK and some discomfort is understandable.  As long as we're not taking a stance that we no longer think running tests in a container is a priority or even in question, we're ok allowing some time to achieve the goal.

Is there anyone who does not agree with this long-term goal?


-David