Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] Discussion on handling of standalone TCKs in JESP

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)    

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

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.
_______________________________________________ mailing list
To unsubscribe from this list, visit

Back to the top