Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-tck-dev] discussion around jakartaee-tck/issues#51 and Turning TCK into a multi-dependency maven project

Scott Marlow wrote on 5/23/19 5:42 AM:
> On 4/22/19 5:11 PM, Bill Shannon wrote:
>> In some cases a spec will have "conditional requirements" that apply only
>> when it is part of a Java EE product; tests for those requirements ought
>> to move the the TCK to the spec project.
> 
> Anything is possible but I suspect that some spec projects, will prefer to only
> focus on the technologies that are in that spec project.  So, those tests might
> not get the love that they deserve, in new revisions of the spec project that
> are aligned with a new Jakarta EE release/version.

I think it's up to the PMC and the Spec Committee to decide what's acceptable.

> It just isn't possible to make everyone happy on this effort to split the
> CTS/TCKs up, in that I think there will be pain somewhere, regardless of which
> options we follow for splitting the CTS/TCKs up.

Agreed.

>> Some other tests are for requirements in the platform spec; those tests
>> ought to remain with the CTS.
> 
> Agreed.
> 
>>
>> I don't know how easy it will be to determine which tests fall into the
>> above categories.
> 
> I have been worried about chicken and egg situations, where tests might live in
> a standalone TCK but require various containers to run the test.

Yup.  Obviously some "standalone" TCKs are still going to require running
in a container, e.g., JSP.

> If a spec project is designing a new revision to be part of a new Jakarta EE
> release/version (e.g. Jakarta EE 20), the spec project could test with
> containers from the last released Jakarta EE release/version (e.g. Jakarta EE
> 19, but the spec project TCK tests, won't be able to use newer container
> features being added to Jakarta EE 20 (at least not easily, since Jakarta EE 20
> container implementations might not be available yet).

A spec could certainly decide to support older versions of the platform.
Some of our existing specs have taken that approach.

> I'm not arguing for/against here, just trying to discuss some of the challenges
> with splitting the CTS/TCKs into separate projects, so we can identify pros/cons
> with different approaches.

Understood.


Back to the top