| [jakartaee-spec-project-leads] Jakarta Batch 2.1 + CDI integration ? Optional features or not, and TCK implications |
Hi,
In the Jakarta Batch 2.1 (for EE10) discussion we've debated how to define Jakarta Batch + CDI integration, given the JSR 352 legacy where we tried to position Batch as DI-netural, partly to allow Spring Batch + Java EE implementations to all implement JSR 352.
The recent discussion sort of reached a consensus on "CDI + Batch integration will be well-defined and required, whenever CDI is present" (leaving it open that CDI could very well be absent, e.g. in a Spring Batch env.).
Now, my usual apologies for not really keeping up-to-date and having to catch up on these discussions... but Scott Stark's comment on our Plan Review PR: https://github.com/jakartaee/specifications/pull/381#issuecomment-849791987 that Jakarta intends to avoid "optional" features seemed to align with just fine with our thoughts.
Turning to the TCK, in my mind, "no optional features" would imply "no optional tests", and that the Batch TCK would need to do something like detect the absence of CDI and "no-op" the rest of the test. We're basically shifting complexity from the spec process, where we can simply say "all behaviors are required" and moving into the TCK logic, where this one "behavior" has a complicated "if CDI present,,..xyz... / else no-op ..." fork in it.
However, it was also suggested in: https://github.com/eclipse-ee4j/batch-tck/issues/20 that we could use subdir paths / patterns to signify which test relate to CDI and declare some kind of "profile". Could that work and be covered by the Spec/TCK processes (in which case moving the complexity to the test logic is just making things more convoluted)?
Appreciate your thoughts. Thanks,
------------------------------------------------------
Scott Kurz
WebSphere / Open Liberty Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------