Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Pattern for designating certain standlone TCK tests as EE-only?

Hi Scott,

FYI, we are having two TCK zoom calls on September 8, first at 7am EST + second at 5pm EST.  We will send a reminder on the Platform TCK mailing list for the call but you should be able to access the calendar via https://calendar.google.com/calendar/u/0/embed?src="">.  The agenda link is https://docs.google.com/document/d/1V1dDLJkd14EDRMPeuI0VzPtU4Lbli8FFBd1pLDLlOrY/edit#

On 8/17/21 4:47 PM, Scott Kurz wrote:

Thanks for the responses and pointers.

Let me echo back what I think I'm hearing from Scott M. and Scott S. (on CDI).     I think you're suggesting:

  * Have the component TCK: Batch, CDI, etc. define a group of EE tests (e.g. "javaee-full") separate from the test of the tests.
  * When certifying against the component standalone TCK, make this EE group optional
  * Have the Platform TCK pull in all the component tests, with the EE group required (along with the rest of the component tests and the rest of the platform TCK)

+1


That seems like a good answer.     So why was I trying so hard to overcomplicate this?

Let me just back up and note that the Batch spec says:        When running on a Jakarta EE platform, the batch runtime uses global transactions  and describes how to set the tran timeout in the batch job XML.

Well, if there's a statement in the Batch spec... doesn't it seem reasonable that the Batch TCK should validate it?    Is that only the Platform TCK's responsibility, because this is platform-level behavior?   

Good question.  IMO, from the perspective of the TCK user, they might want to specify that all technologies required by the Jakarta EE Platform specification should be tested, which would include testing with global transactions. 



 I do think it's easy to rationalize and explain this as:

* Platform level behaviors may only be validated in the platform TCK

This seems fine since that is what Batch has supported up to now. 


* The Platform spec is essentially the combination of the individual component specs plus the details specified at the platform integration level spec document

But wanted to make sure others agreed with this interpretation.

+1 on getting feedback from others.


On another note:  for component projects we don't issue "compatible in EE" vs. "compatible in SE"  designations but simply certify implementations as "compatible".     Maybe we really do mean "compatible in SE"?

IMO "compatible in SE" mode means that the Batch implementation is tested using technologies available via the base Java SE version (e.g. Java SE 11+ for specifications that are part of Jakarta EE 10). 

Also IMO, if the Batch SPEC team wants to support testing of other technologies in Java SE, that comes at a cost to the Batch SPEC team (in terms of maintaining the complexity of verifying that the additional technology can be passed in Java SE). 



I still wish I understood the overlap between platform and component certification better... but I'll stop there in case no one wants to take this any further.  I think I see a path forward now. 

I would like to take this further but perhaps as a separate response. :-)


Thanks,
------------------------------------------------------
Scott Kurz
WebSphere / Open Liberty Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------

Inactive hide details for "Scott Marlow" ---08/17/2021 04:09:39 PM---On 8/17/21 11:32 AM, Scott Kurz wrote: >"Scott Marlow" ---08/17/2021 04:09:39 PM---On 8/17/21 11:32 AM, Scott Kurz wrote: >

From: "Scott Marlow" <smarlow@xxxxxxxxxx>
To: "jakartaee-platform developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx>, "Scott Kurz" <skurz@xxxxxxxxxx>
Date: 08/17/2021 04:09 PM
Subject: [EXTERNAL] Re: [jakartaee-platform-dev] Pattern for designating certain standlone TCK tests as EE-only?




On 8/17/21 11:32 AM, Scott Kurz wrote: In batch we have some function (integration with JTA global transactions) required in EE-only. As we continue to phase out the Batch portion of the Platform TCK and use our Batch standalone TCK instead, ZjQcmQRYFpfptBannerStart 
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd

On 8/17/21 11:32 AM, Scott Kurz wrote:


    In batch we have some function (integration with JTA global transactions) required in EE-only.

    As we continue to phase out the Batch portion of the Platform TCK and use our Batch standalone TCK instead, how do we "guard" the tests accordingly?

Users currently use the Platform TCK `keywords` to opt into different technologies via options like {javaee, javaee_web_profile, javaee_optional, javaee_web_profile_optional } specified via command line options passed into Ant.  I have not had the pleasure of running the standalone Batch TCK yet but assume that currently just assumes it is doing an "SE run", sound right? 

    Is there already a pattern for dealing with this in other component TCKs?

As Scott Stark mentioned, the CDI TCK already does deal with this (via TestNG). 

For JUnit5, https://junit.org/junit5/docs/5.7.1/api/org.junit.platform.launcher/org/junit/platform/launcher/LauncherDiscoveryRequest.html might help to influence whether the SE or EE tests are discovered and run.



    Some ideas:

    1. Test for EE and run/ignore/no-op accordingly
          Do a JNDI lookup of     java:comp/UserTransaction and if it fails dynamically ignore all the test methods in the class
    (a slight variant would be to pass the tests rather than ignoring.  

    2. Add SE vs EE config
       Add some other external switch/config so that the user executing the TCK has to explicitly choose if they're doing an "SE run" or an "EE run" ... with the JTA tests only getting executed in EE.

    3. Move the EE set of tests into the platform TCK

Would this be everything under the https://github.com/eclipse-ee4j/batch-tck/tree/master/com.ibm.jbatch.tck/src/main/java/com/ibm/jbatch/tck/tests/ee folder and everything else needed from Batch would be available as a Maven artifact? 

    ---

    Does 1. seem like an allowed approach, given the overall Eclipse / Jakarta specification rules?  

    Do we need to worry about a case where the     java:comp/UserTransaction lookup fails on a supposed EE-compatible implementation, thereby ignoring tests which should have been executed?  

    Say one had a modular implementation where transactions or even JNDI had to be optionally activated/enabled.... is there a concern that this implementation could certify against Batch and go on to certify against all components in the platform but without ever having run the "Batch EE" tests?

    I think that's probably enough detail to help route this conversation to where it needs to happen.. either the right list or maybe the monthly call, so please let me know.

    Thank you,
    ------------------------------------------------------
    Scott Kurz
    WebSphere / Open Liberty Batch and Developer Experience
    skurz@xxxxxxxxxx
    --------------------------------------------------------


    _______________________________________________
    jakartaee-platform-dev mailing list
    jakartaee-platform-dev@xxxxxxxxxxx
    To unsubscribe from this list, visit     https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev




Back to the top