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

[Scott Stark <sstark@xxxxxxxxxx>]

Not in general because a component specification that has an SE or non-profile bound mode of operating also has an implementation that is capable of running in that mode. So Weld can be used to verify the SE expectations of CDI, as well as the Core, Web Profiles and the Platform as it is embeddable into implementations that support those containers.

We need to standardize on a testing framework that supports grouping of tests, deployment archives, containers to handle the deployment archives, and composability via maven to properly describe how specifications manage their tests and composition into integration tests of profiles.

On Wed, Apr 6, 2022 at 1:35 PM Thomas Watson <tjwatson@xxxxxxxxxx> wrote:

Will that not put a burden on implementations that really can only be verified in the context of the platform or web profile?

It seems they would have to wait until the platform TCK is completed before being able to be used as a compliant implementation for a ballot of an individual specification.

Tom

---

From: jakarta.ee-spec.committee <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx> on behalf of Scott Stark <sstark@xxxxxxxxxx>
Sent: Wednesday, April 6, 2022 1:29 PM
To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Subject: [EXTERNAL] Re: [jakarta.ee-spec.committee] Requirements for individual specification TCKs

 

So this set of 3 types of tests do exist in the CDI TCK for example, but in general, there is still a problem with this way of organising tests that leads to circular dependencies due to TCK tests depending on APIs of downstream specifications. ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

So this set of 3 types of tests do exist in the CDI TCK for example, but in general, there is still a problem with this way of organising tests that leads to circular dependencies due to TCK tests depending on APIs of downstream specifications. For example, CDI depends on servlet, EJB, JMS, ... for its Web Profile based tests. 

I think the ideal way to structure this is to have these Profile integration tests in separate artifacts that are part of the Profile TCK. The problem then becomes who owns the tests and how are they released? I would argue it should be a collaboration between the spec team and the platform team and live in a profile specific submodule of the platform TCK project that is released as part of the associated profile release.

On Tue, Apr 5, 2022 at 9:24 AM Thomas Watson <tjwatson@xxxxxxxxxx> wrote:

Hi all,

It is not clear that the specification committee has discussed and decided on the requirements for individual specification TCK execution (aka standalone TCK).  Recent discussions about individual specification TCKs have identified an exposure for a platform implementation to claim compliance for individual specifications that are included in the platform, web profile or core profile.  A TCK must be executable within the context of the profile it is included in: platform, web profile or core profile.  ​Otherwise, there is no confirmation that the compliant platform, web profile or core profile implementation functions properly with respect to the individual specification TCK.

Some individual specification TCK teams have indicated the desire to develop TCKs that are only executable outside of a profile implementation and only run directly on Java SE.  It is acceptable for specification projects to develop a TCK that can run directly on Java SE.  It is not acceptable for that complete TCK to only be executable directly on Java SE.

A TCK can have three types of tests:

1. Tests that only apply when running outside of a platform (or profile), such as on Java SE, to test behavior defined by the specification for that mode of execution.
2. Tests that only apply when running in a platform (or profile) to test behavior defined by the specification for that mode of execution.
3. Tests that apply to the behavior defined by the specification for all modes of execution.

The tests of type 2 and 3 must be able to be executed in the context of the profile they are included in: platform, web profile or core profile.

We want to discuss proposing the following requirements for individual specification TCKs within the specification committee:

1. The individual specification TCK must provide a profile-ready mechanism for running the required TCK tests (types 2 and 3) in the profiles they are included in: platform, web profile or core profile. Type 1 tests must be excluded and not required to be executed.
2. The individual specification TCK must provide a mechanism for running the required TCK tests (types 1 and 3) outside the context of a platform or profile such as on Java SE. Type 2 tests must be excluded and not run.
3. It is important that type 3 tests be run in compatible implementations of the profiles to validate the individual specification implementation functions properly in the profile implementation: platform, web profile or core profile.

Note that we avoided using the term "standalone TCK" because to some the term "standalone" means TCKs that run outside of any platform or profile container.

Thomas Watson

_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee

_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee