| Re: [jakartabatch-dev] 2.1 Plan Review PR - Review Ballot to follow |
I think it is worth asking Michael too, on behalf of Spring Batch, if this seems valuable, since the bypass of CDI is mainly for Spring Batch at this point in time... as well as more generally if he had any more recent thoughts about Spring Batch and whether to go forward with Jakarta Batch 2.1.
Under my proposal it wouldn't be possible for Spring Batch to certify Jakarta Batch running on top of an EE platform (where CDI will be present) without integrating with CDI.
I'd guess that'd not be a problem since Spring Batch could certify on SE and if you wanted to enable Spring Batch in an EE server, well, they might need to have a way to disable CDI anyway. But I'm not sure I've thought that through all the way.
Thanks,Romain Manni-Bucau ---05/28/2021 02:24:45 PM---CDI.current() is in CDI spec but it is broken in several weld based containers so while not mentionn
From: Romain Manni-Bucau <rmannibucau@xxxxxxxxx>
To: jakartabatch developer discussions <jakartabatch-dev@xxxxxxxxxxx>
Date: 05/28/2021 02:24 PM
Subject: [EXTERNAL] Re: [jakartabatch-dev] 2.1 Plan Review PR - Review Ballot to follow
Sent by: "jakartabatch-dev" <jakartabatch-dev-bounces@xxxxxxxxxxx>
Hi,
I know we haven't really seen any activity, but in any case, I did take the next step forwards with 2.1 and submit the Plan Review PR:
https://github.com/jakartaee/specifications/pull/381/files
I'd expect a formal review ballot to follow shortly, though I couldn't tell you exactly when.
I think there's time before the ballot starts for comments though.
I tried not to pin things down too specifically.. I did reference our milestone: https://github.com/eclipse-ee4j/batch-api/milestone/1 but expect the content to be flexible depending on what we actually agree to, write up, and implement.
Let me note the text I wrote around CDI, since that's certainly been an area of discussion/debate:
I was told that Jakarta's avoiding "optional" features, (and I agree with this approach). Basically I'm saying CDI integration is "required when present".
Exact text:
```
### CDI integration defined (when CDI present)
When CDI is present, as within the Jakarta EE Platform, then the integration of Jakarta Batch + CDI will be well-defined and required for an implementation to be certified as Jakarta Batch-compliant. However, an implementation should be able to certify full Jakarta Batch compliance in the absence of a CDI implementation, e.g. if is certifying itself as a Jakarta Batch implementation but not a Jakarta EE Platform implementation.
The working design for detecting the presence of CDI assumes the TCK would do something like call `CDI.current()`, and, if a `null` value is returned, "no-op" (immediately pass) the relevant tests.
```
So I don't think it'd be possible for an impl to achieve Jakarta EE Platform compliance without implementing Batch + CDI integration, and I don't think it'd be possible to certify Jakarta Batch compliance within an EE platform impl. But it should be possible to achieve Jakarta Batch compliance without any CDI integration, as long as CDI is not part of the SE platform.
I did catch Romain's point that CDI.current() was somehow Weld-specific but I'm not familiar with this and don't know what to write better, plus called this a "working design"... I think it conveys the goal we're aiming for.
Feel free to comment, on this list, or on the PR.
Thanks,
------------------------------------------------------
Scott Kurz
WebSphere / Open Liberty Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------
_______________________________________________
jakartabatch-dev mailing list
jakartabatch-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartabatch-dev
