Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartabatch-dev] GitHub milestones for EE 10 , Batch 2.1 (tentative)

Though I floated the idea of making CDI + Batch integration a hard requirement, that was just one of a few options. The consensus seems to have steered more towards making CDI + Batch integration optional.

Though one could ask: "how is that different from the status quo?", my answer is that we should require specific behavior in the presence of CDI, and validate this in the TCK, whereas today the TCK and spec say nothing at all about this.

I'm hearing from Romain that other specs/TCKs provide for this type of "CDI optional" stance (JSF?) ... but I'm not familiar with the details. We need to formalize this beyond just an informal agreement that you can choose to not run certain tests and describe your impl differently.

If no one here is familiar enough to point to the formal approach used in these other specs I can do some research and get back to us.
---

That all said, Michael, do you see the rough approach of "formally defining the integration of Batch + CDI, where CDI is optionally present" as breaking Spring Batch apps? I would think not so I'd like to learn more about your concern.

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

Inactive hide details for Romain Manni-Bucau ---04/06/2021 01:44:41 AM---Le mar. 6 avr. 2021 à 00:30, Michael Minella <mminellaRomain Manni-Bucau ---04/06/2021 01:44:41 AM---Le mar. 6 avr. 2021 à 00:30, Michael Minella <mminella@xxxxxxxxxx> a écrit : > Do keep in mind that

From: Romain Manni-Bucau <rmannibucau@xxxxxxxxx>
To: jakartabatch developer discussions <jakartabatch-dev@xxxxxxxxxxx>
Date: 04/06/2021 01:44 AM
Subject: [EXTERNAL] Re: [jakartabatch-dev] GitHub milestones for EE 10 , Batch 2.1 (tentative)
Sent by: "jakartabatch-dev" <jakartabatch-dev-bounces@xxxxxxxxxxx>







Le mar. 6 avr. 2021 à 00:30, Michael Minella <mminella@xxxxxxxxxx> a écrit :
    Do keep in mind that the Spec as it currently exists does not have any CDI specific functionality in it. The alignment to CDI may break implementations. For example, I wouldn't expect Spring's DI to work going forward which is obviously breaking for us.

Strictly speaking it is already there since at least batch property injection are cdi oriented so components can be CDI beans by design, so no breaking change to add more about CDI for spring: https://github.com/eclipse-ee4j/batch-api/blob/0019b27531b3b7d640555bbec94ec7cf3285beca/api/src/main/java/jakarta/batch/api/BatchProperty.java#L41.
Once again, Spring JBatch implementation already bypasses CDI support so will not change much.
That said there is no feature Spring will not support almost natively AFAIK, Spring has an event bus too, Spring has scopes too so sounds all good, TCK just needs to ensure both features are abstracted in the test and the vendor must provide the impl to let the TCK be abstract.
It is the way all specs do it and not sure the point to make JBatch different since at the end it does not prevent Spring usage at all - you can take JAXRS as an example, Spring does not respect the CDI part but Spring users are still happy to use it from what I saw.
 

    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 Reza Rahman <reza_rahman@xxxxxxxxx>
    Sent:     Monday, April 5, 2021 5:11 PM
    To:     jakartabatch developer discussions <jakartabatch-dev@xxxxxxxxxxx>
    Subject:     Re: [jakartabatch-dev] GitHub milestones for EE 10 , Batch 2.1 (tentative)
     
    It’s a tough call. As such, the CDI features would not break backwards compatibility in the sense that it is defined in the platform: https://eclipse-ee4j.github.io/jakartaee-platform/CompatibilityRequirements.

    The changes slated are interesting enough, but probably not significant enough to warrant being a major release. Maybe if there are more substantive feature changes it could warrant being considered major other than essentially CDI and Java SE version alignment.

    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 Apr 5, 2021, at 12:08 PM, Michael Minella <mminella@xxxxxxxxxx> wrote:

        
        Is this intended to be a 2.1 (backwards compatible) or a 3.0 (breaking changes allowed) release? A quick scan through the issues makes me think this should be more of a 3.0 than a 2.1. Specifically:
          • CDI requirement is a breaking change.
          • Adding generics and a Java API, while not a breaking change, is a change big enough IMHO to warrant a major version bump.
        Thoughts?

        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 Reza Rahman <reza_rahman@xxxxxxxxx>
        Sent:         Sunday, April 4, 2021 9:36 AM
        To:         jakartabatch developer discussions <jakartabatch-dev@xxxxxxxxxxx>
        Subject:         Re: [jakartabatch-dev] GitHub milestones for EE 10 , Batch 2.1 (tentative)
         
        This looks pretty good to me. Hopefully other folks chime in too.

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



Back to the top