Can the cdi-api version be updated?

[liweinan]

No description provided.

[liweinan]

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

[scottkurz]

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

[liweinan]

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?

[scottkurz]

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.

[liweinan]

@scottkurz Thanks for the answer Scott!

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