Re: [jakarta.ee-spec] Discussion on handling of standalone TCKs in JESP

["Kevin Sutter" <sutter@xxxxxxxxxx>]

I agree, Scott.  (And,
thanks for starting a new thread and not polluting the ballot thread for
CDI 3.0.)

We are supposed
to be testing the standalone implementations to the best of one's ability
in a standalone environment.  As these standalone CIs and TCKs are
brought into the Platform, additional variables will come into play with
the overall runtime and testing.  We may find issues that need to
be addressed as the different parts are merged into the Platform CI and
TCK -- like what we found with the web profile testing and CDI.  We
should address those issues as they surface.  But, that type of integration
testing should not negate the standalone CI and TCK that was used for the
standalone ballot.

---------------------------------------------------
Kevin Sutter 
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn: https://www.linkedin.com/in/kevinwsutter



From:
       Scott
Stark <starksm64@xxxxxxxxx>
To:
       Jakarta
specification disccusions <jakarta.ee-spec@xxxxxxxxxxx>
Date:
       09/14/2020
11:56
Subject:
       [EXTERNAL]
[jakarta.ee-spec] Discussion on handling of standalone TCKs in JESP
Sent
by:        jakarta.ee-spec-bounces@xxxxxxxxxxx

---

I wanted to start a separate discussion
so as not to pollute the current CDI voting thread. Tomitribe included
the following comment in their vote:

"Our +1 comes with the caveat
that we're aware the Compatible Implementation does not pass all tests
contained in the TCK and this is not strictly ok per the JESP which requires
all optional TCK tests to have been passed.  The +1 is an acknowledgment
that "we are where we are" and to address this for CDI would
take a significant amount of work.  Other specifications over the
coming years should not use CDI as an example it is ok to not pass optional
tests."

The issue is not about optional tests,
it is about the TCK containing tests that cover the 3 parts of the specification;
core, Java SE and Jakarta EE. There are integration tests that only apply
to the Jakarta EE web and full profiles.

The current compatible implementation
used with the wave 3 ballot covers the core and Java SE parts of the specification.
Before finalizing the current staged TCK, it had been verified that the
full platform compatible implementation was passing the full TCK. An issue
came up in the web profile testing where CDI integration code was pulling
in an invalid dependency on an optional specification API. 

The issue we have is that specifications
are producing APIs that have explicit dependencies, and this is determining
their release order, but they also talk about integration requirements
with EE platforms.

This is a broken circular model. What
we should be doing is producing addendums to the various platform specifications
and producing a separate test library that is to be integrated by the platform
TCKs. 

CDI integration with the EE platforms
should really be voted on as part of the platform specification and TCK
work. Bean Validation has a similar situation.

I don't view this as an issue requiring
any changes to the JESP, rather it is an operational artifact from a time
when there was a lack of openness in TCKs, specifications and even APis.
We simply need to restructure projects to align artifacts with the appropriate
specification level.
_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec