[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakartaee-spec-project-leads] Jakarta Batch 2.1 + CDI integration ? Optional features or not, and TCK implications
|
On 5/28/21 6:26 PM, Scott Kurz wrote:
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.
For EE 9.1, we considered taking a similar
approach (via TCK `keywords`) for handling `org.omg.CORBA.ORB`
references on JDK11 but didn't since the CORBA references in
Platform TCK tests would likely cause ClassNotFound problems
with JVMs that eagerly load classes.
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)?
The Platform TCK and produced TCKs rely on `keywords` to do
this. With the CORBA situation mentioned above, I naively wanted
to do this but the level of test refactoring to separate the
relevant test source into different subdir paths/patterns, was too
much change for the Jakarta EE 9.1 release.
There are cases where we did succeed in separating test sources
into separate subirectories, for example see xmlbinding in
https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/com/sun/ts/lib/harness/keyword.properties#L481
.
Appreciate your thoughts.
Thanks,
Also, we will soon have a conversation on the
Jakarta Platform mailing about requirements for extracting TCKs
from Platform TCK. This will include a draft proposal document
that will have discussion points for how to handle optional
technologies in EE 10+ TCKs.
Scott
------------------------------------------------------
Scott Kurz
WebSphere / Open Liberty Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------
_______________________________________________
jakartaee-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads