|Re: [jakartaee-platform-dev] Spec process for certification against SPEC TCK running in an EE env|
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:
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.
WebSphere / Open Liberty Batch and Developer Experience
jakartaee-platform-dev mailing list
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
Back to the top