Skip to main content
[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

Thank you Scott for your reply,

As we talked about this more on the batch ML, the plan is now coalescing into simply requiring CDI integration, (for better app portability, better platform integration, and a simpler spec process as well).
https://www.eclipse.org/lists/jakartabatch-dev/msg00182.html

But talking this all through helped us get to this point, so appreciate the advice,
------------------------------------------------------
Scott Kurz
WebSphere / Open Liberty Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------

Inactive hide details for Scott Marlow ---05/29/2021 06:58:16 AM---On 5/28/21 6:26 PM, Scott Kurz wrote: >Scott Marlow ---05/29/2021 06:58:16 AM---On 5/28/21 6:26 PM, Scott Kurz wrote: >

From: Scott Marlow <smarlow@xxxxxxxxxx>
To: JakartaEE Spec Project Leadership discussions <jakartaee-spec-project-leads@xxxxxxxxxxx>, Scott Kurz <skurz@xxxxxxxxxx>
Date: 05/29/2021 06:58 AM
Subject: [EXTERNAL] 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 ZjQcmQRYFpfptBannerStart 
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd

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



GIF image

Back to the top