Re: [jakartabatch-dev] 2.1 Plan Review PR - Review Ballot to follow

["Scott Kurz" <skurz@xxxxxxxxxx>]

Thanks Michael for sharing this update.  

I'm going to re-draft the Plan Review then to simply note that we will be defining a required   CDI integration, unless we hear other objections.  

I think this makes a lot of sense.   In addition to the value to the users who can now more simply expect that Jakarta Batch comes with Jakarta CDI integration like the rest of the Jakarta platform...it's also a significant simplification for the spec maintainers (us).  
Managing this divergence is a non-trivial effort and will let us focus on function and the rest of the project.

A potential downside though is losing some of your contributions.  

Not trying to be overdramatic nor trying to kick you off the list :), as always we welcome your expertise and opinions going forwards.

But let me take a quick moment to stop and thank Michael, VMWare, and all who've contributed their contributions, ideas, time, careful review and the like to JSR 352 and Jakarta Batch, and playing such a key role in the project so far.
I feel like this deserves more than a footnote in a reply thread but coming off a long weekend that's all I've got at the moment :)

I will also stop and pass around some credit to all of us who have been involved in this DI vs CDI discussion going back.   It has always been a tricky issue to handle, but I think this forum has always handled it civilly, and transparently as possible, and have served as an example of a polar opposite to plenty of negative technology discussions we've probably all seen.     So thanks to all who've helped keep it this way.

Thanks,
------------------------------------------------------
Scott Kurz
WebSphere / Open Liberty Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------

Michael Minella ---06/01/2021 09:17:28 AM---All, Thanks for this. A couple notes:

From: Michael Minella <mminella@xxxxxxxxxx>
To: jakartabatch developer discussions <jakartabatch-dev@xxxxxxxxxxx>
Date: 06/01/2021 09:17 AM
Subject: [EXTERNAL] Re: [jakartabatch-dev] 2.1 Plan Review PR - Review Ballot to follow
Sent by: "jakartabatch-dev" <jakartabatch-dev-bounces@xxxxxxxxxxx>

---

All,

Thanks for this. A couple notes:

1. Spring Batch has never been able to certify in an EE environment due to the structure of the TCK (it's requirement to run a full test suite for a container which Spring Batch obviously cannot do). Because of that, our implementation has always felt like one that wasn't fully baked.
2. As you pointed out, CDI is the direction the entire Jakarta platform is going. It makes sense and holding back Jakrata Batch for an implementation that can't fully certify in the first place doesn't make sense for the broader community.
3. Spring Batch logged this issue (https://github.com/spring-projects/spring-batch/issues/3894) to depricate our implementation of the JSR a month ago and as we expected, we have not received any pushback from the community. As of right now, it is our intention to depricate our JSR-352 implementation with Spring Batch 5 and remove it in a few years with Spring Batch 6.

I hope this helps the decision process going forward. Let me know if you have any other questions or concerns.

Thanks,
Michael Minella (He/Him)
Sr. Manager - Spring Engineering
mminella@xxxxxxxxxx
3401 Hillview Avenue, Palo Alto, CA 94304

---

From: jakartabatch-dev <jakartabatch-dev-bounces@xxxxxxxxxxx> on behalf of Scott Kurz <skurz@xxxxxxxxxx>
Sent: Friday, May 28, 2021 5:51 PM
To: jakartabatch developer discussions <jakartabatch-dev@xxxxxxxxxxx>
Subject: 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>

---

CDI.current() is in CDI spec but it is broken in several weld based containers so while not mentionned in the text it is fine. Detection is up to the vendor - does not impact users so no issue to not say how it is done IMHO.

To enable spring - i guess it is about spring batch - to be certified we need a jbatch standalone explicit coverage which would be the SE certification I guess.
Should just be a matter of referencing a set of tests to pass for this sub-ee certification - otherwise it does not make much sense to reference it, wdyt?

Le ven. 28 mai 2021 à 18:11, Reza Rahman <reza_rahman@xxxxxxxxx> a écrit : 
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

_______________________________________________
jakartabatch-dev mailing list
jakartabatch-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartabatch-dev_______________________________________________
jakartabatch-dev mailing list
jakartabatch-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartabatch-dev



_______________________________________________
jakartabatch-dev mailing list
jakartabatch-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartabatch-dev