Code Monkey home page Code Monkey logo

Comments (5)

scottkurz avatar scottkurz commented on June 21, 2024 1

@liweinan, good question.

Let me first address the process involved.

PROCESS STEPS

First, the specification document doesn't go into a level of detail which would re that would require any doc updates in upgrading, so no issue there.

I still think, according to the JESP, we would need to do a "Service Release" in order to release a new update of the API JAR.
So we'd need to do a PR: https://github.com/jakartaee/specifications/pulls

Ultimately I think the TCK should at least be re-executed against the jbatch impl using the updated API JAR.

USE CASE

That all said, could you please explain what you see as the value here?

I assume you're suggesting to upgrade the dependency version in the 'jakarta.batch-api'. Since this is only a provided-scoped dependency, though, it isn't picked up transitively by consumers of 'jakarta.batch-api'.

I'm curious then how this would help?

from batch.

scottkurz avatar scottkurz commented on June 21, 2024 1

With your teaching and my understanding, as the jakarta.batch-api is a provided scope dependency only in here, I guess I don't have to keep the cdi-api dependency version aligned within JBeret, is that correct?

That's correct. We haven't had any kind of "breaking" compile change in a long time, so it shouldn't be a concern.

from batch.

liweinan avatar liweinan commented on June 21, 2024 1

@scottkurz Thanks for the answer Scott!

I'll close this issue/question as its confirmed/answered :D

from batch.

liweinan avatar liweinan commented on June 21, 2024

@scottkurz There is `cdi-api 4.1.0' coming out: https://github.com/jakartaee/cdi/releases/tag/4.1.0

And it seems this upgrade can work with JBeret: jberet/jsr352#511

Can this upgrade be included in batch side?

from batch.

liweinan avatar liweinan commented on June 21, 2024

Adding @jamezp and @scottmarlow into the loop.

@scottkurz Thanks for the detail explanation!

The reason I'm asking is that I plan to upgrade the cdi-api in JBeret side, and the JBeret itself uses the dependency in its detail implementation(The https://github.com/jberet/jsr352/blob/main/jberet-core/src/main/java/org/jberet/creation/BatchCDIExtension.java for example).

With your teaching and my understanding, as the jakarta.batch-api is a provided scope dependency only in here, I guess I don't have to keep the cdi-api dependency version aligned within JBeret, is that correct?

from batch.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.