Skip to main content

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

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.

Back to the top