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

["Scott Kurz" <skurz@xxxxxxxxxx>]

Thanks Scott S.,

But to my knowledge there's no concept of targeting one platform vs. another when certifying an impl against a component/spec like Batch or CDI, e.g. in the TCK process
https://jakarta.ee/committees/specification/tckprocess/

One way I can see rationalizing this situation would be to say that this Batch spec statement:

When running on a Jakarta EE platform, the batch runtime uses global transactions.

is NOT a Batch spec-level statement but ONLY a platform-level statement, and therefore does NOT need to be validated via the component/spec-certification but ONLY by the platform TCK.


Now, that all said.. the batch project should be allowed to say that either the SE-only or full EE suite can be used to certify against the component, (if an impl would rather run the EE suite).   It can also make it easy for the TCK / certification results to show evidence that an impl was run against the EE suite.

But the Batch project can't create on its own two categories of compliance:  compliance within EE, compliance outside of EE.

At least this interpretation is making sense to me but it's really up to the platform team to agree this is indeed the spec process in a case like this.

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

"Scott Stark" ---10/19/2021 10:30:42 AM--- The way it is done in CDI is that there are sets of tests that target the different environments, a

From:        "Scott Stark" <starksm64@xxxxxxxxx>
To:        "jakartaee-platform developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx>
Date:        10/19/2021 10:30 AM
Subject:        [EXTERNAL] Re: [jakartaee-platform-dev] Spec process for certification against SPEC TCK running in an EE env
Sent by:        "jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx>

---

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_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev