All looks good to me. Thanks for doing this!
Reza Rahman Jakarta EE Ambassador, Author, Blogger, Speaker
Please note views expressed here are my own as an individual community member and do not reflect the views of my employer. On May 28, 2021, at 11:36 AM, Scott Kurz <skurz@xxxxxxxxxx> wrote:
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
|
