[
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.