User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0
On 4/6/22 6:20 PM, Emily Jiang wrote:
>What we are doing for EE10 is to duplicate tests that
exercise the expected integration points that are most likely
needed in the various EE containers. No one was willing to make
test reuse a blocking requirement for EE10, so that is the best
we can do.
To be honest, this is the gap we should look at urgently instead
of saying this is the best effort we can do.
More concerning to me is being able to respond in a timely
fashion to Java SE 21 support since that is actually user facing.
Having said that, we could make completing the refactoring of the
Platform TCK a blocking requirement of the next EE release even if
its comes at the cost of timely Java SE 21 support.
If we plan to block the next EE release until the TCK refactoring
is done, we won't get stuck in the middle of the EE.next release
with an incomplete TCK implementation which was a concern with EE
10 (since we wanted a quick release).
What we are doing for EE10 is to duplicate
tests that exercise the expected integration points that are
most likely needed in the various EE containers. No one was
willing to make test reuse a blocking requirement for EE10, so
that is the best
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
What we are doing for EE10 is to duplicate tests that
exercise the expected integration points that are most
likely needed in the various EE containers. No one was
willing to make test reuse a blocking requirement for EE10,
so that is the best we can do.
> 1. Run the standalone SE based TCK against
the implementation jar. The JSONP TCK docs describe
how to do this by setting the GAV maven coordinates
of the vendor implementation.
In this case, the tests are SE only and they can't be
executed in an EE container. How can we ensure to the
customers that JSON-P behaves as specified without
tests backed up in that context?
e.g. a snake swims well in cold water (e.g. SE). It
might not function well in warm water (e.g. EE).
I totally agree with what David said: This is why
we run the same test several times, once as a
Servlet, again as a JSP, again as an EJB, etc. To
go from that to the extreme of it not being testable
in a container at all is too far of a departure IMO.
I think it is ok to run some tests in SE container,
but these tests should also be executable in EE if
the functionalities are applicable to EE.
Taking
JSONP as an example, for EE10 the discussion we had
was that the requirements would be: 1. Run the
standalone SE based TCK against the implementation
jar. The JSONP TCK docs describe how to do this by
setting the GAV maven coordinates
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your
organization.
ZjQcmQRYFpfptBannerEnd
Taking JSONP as an example, for EE10
the discussion we had was that the requirements
would be:
1. Run the standalone SE based TCK against the
implementation jar. The JSONP TCK docs describe
how to do this by setting the GAV maven
coordinates of the vendor implementation.
2. The platform TCK would keep the integration
only tests to validate basic container level
integration.
For EE 10
we have several new individual TCKs. I
would like to understand if we established
any general policies for how such TCKs are
executed. I'm asking for a general
discussion about such a policy. But if it
helps to have some examples I am referring
to the TCKs for the individual
specifications JSON Binding, JSON Processing
and XML Binding. My understanding of these
three individual TCKs is that they are only
able to be run directly against Java SE.
Is there a
specific individual Jakarta EE specification
TCK that you are referring to? Perhaps one
of the new for EE 10 TCKs? Scott On 4/5/22
10:24 AM, Thomas Watson wrote:
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your
organization.
ZjQcmQRYFpfptBannerEnd
Is there a specific individual Jakarta EE
specification TCK that you are referring
to? Perhaps one of the new for EE 10 TCKs?
Scott
On 4/5/22 10:24 AM, Thomas Watson 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:
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.
Tests that only apply when running
in a platform (or profile) to test
behavior defined by the specification
for that mode of execution.
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:
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.
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.
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.