Re: [jakartaee-platform-dev] Spec process for certification against SPEC

[Scott Stark <starksm64@xxxxxxxxx>]

The way it is done in CDI is that there are sets of tests that target the different environments, and the TCK docs talk about how to run each based on what environment you are targeting. For web and full testing you need to run with a flag to indicate that. 

If some EE container wants to certify against Batch in SE mode because they are not certifying some profile, they can, and they would follow the instructions for that. It is not up to the Batch TCK to try to detect what environment it is running in. I don't see why a implementation that makes uses of a few EE APIs but is not interested in that level of certification has to pass the EE mode of the Batch TCK. I suppose that is really up to the Batch project however.

On Oct 19, 2021 at 9:16:20 AM, Scott Kurz <skurz@xxxxxxxxxx> wrote:

Let me post a question I raised a bit earlier:  https://www.eclipse.org/lists/jakartaee-platform-dev/msg02756.html).

In short, while it's easy for a standalone spec TCK to separate tests into EE, non-EE "suites" (subsets) using JUnit or whatever technology, it's not clear to me what the certification process workflow should be.

(We touched on this in our Oct. 13 TCK call led by Scott Marlow:
https://docs.google.com/document/d/1V1dDLJkd14EDRMPeuI0VzPtU4Lbli8FFBd1pLDLlOrY/edit#heading=h.s6ehbjf0q1uj
under the section:  "Does the Platform own passing the Batch TCK against EE 10 or does Batch SPEC own that?")
---

E.g. the Batch spec states:
    When running on a Jakarta EE platform, the batch runtime uses global transactions.  In a Java SE or other environment, the batch runtime may use global transactions if available, otherwise the transactional behavior is undefined.  
So imagine a Batch test which uses java:comp JNDI location and a global JTA transaction within the test application logic.  

It is clear that an implementation trying to certify and running in an SE environment should simply not run this test, which should therefore be in the EE only suite.

For an implementation trying to certify against the EE platform TCK the process also seems obvious enough, even with a standalone Batch spec TCK.    The platform TCK will have some set of instructions referencing or pointing to the individual component/spec TCKs.  There will be instructions for Batch, e.g. "go run the EE suite of the Batch standalone TCK", along with instructions for other individual standalone TCKs and whatever aggregate TCK might also exist at the platform level (assuming that part exists).

But what about an implementation that is running in an EE environment BUT not necessarily seeking platform certification ?    (BTW, this has come up with Spring Batch in the past.  While last I heard Spring Batch is not looking to certify against Batch 2.1, it still raises an interesting question).

It seems wrong to say that this impl could be considered Batch compliant, without passing the test I described.      

Does that suggest the TCK should have a "am I running in EE mode?" test, and we run the full suite, but the EE tests are no-ops if the "EE mode?" test fails?

Or should the user select a "suite", EE or non-EE, and the certification should be:  "certified in SE" and/or "certified in EE" ?    

Another interpretation is that "running on a Jakarta EE platform" is meaningful only with respect to seeking EE platform certifcation, which implies this implementation should run against the non-EE suite.    (In this case, better suite names would be "batch platform" vs. "batch standalone" rather than "EE" vs "SE".)
---

To be honest, I'm not sure it's a crisis if we don't clarify this in EE 10.  However as we're looking to more formally separate out the Batch TCK from the Platform TCK it is a grey area of the process that I think we should understand better.

Thanks,
------------------------------------------------------
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