Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jakartabatch-dev] 2.1 Plan Review PR - Review Ballot to follow

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
--------------------------------------------------------

Back to the top