Re: [cdi-dev] [jakartaee-platform-dev] Specification backward compatibil

[Mark Struberg <struberg@xxxxxxxxxx>]

Yes, I (and a few others) stayed away after some time because I really felt not welcome tbh.

You can still read our comments in some tickets and lists.

And I also agree with you that the things which got added to CDI-4.0 are really almost exclusively because of Quarkus and do not really benefit other JakartaEE containers a lot. That was the reason why it imo must been done as optional feature (would have been perfectly fine for me).

But let's get back to my original question:

Jakarta has well documented rules which prevent such backward incompatible changes.

There have been efforts to change those rules, but those seems to never have been VOTEd on nor did they get documented, nor did the ticket ever get resolved.

So basically CDI-4.0 as is contradicts JakartaEE rules. Besides that the spec document is inconsistent in itself as those changes are only done half baked.

What do we do now?

 

LieGrue,

strub

Am 30.01.2023 um 16:01 schrieb Arjan Tijms <arjan.tijms@xxxxxxxxxxx>:

Hi,

On Sat, Jan 28, 2023 at 8:39 PM Mark Struberg <struberg@xxxxxxxxxx> wrote:

does it make sense for users/consumers of Jakarta EE? Is it worth for them, or does it only benefit one certain implementation (which is not even Jakarta EE but seems to be the origin of this change)?

This topic actually did came up in the calls once or twice. Matej&Ladislav mentioned to mainly represent and care for the Quarkus use case. Not even Weld in general, but just Quarkus. CDI Lite specifically specified what Quarkus did, so Quarkus could be certified too. 

Now the question is, is this bad?

Essentially, in its core it isn't IMHO. Each vendor or other party always represents their own primary use case, and many features that have been introduced into the spec in the past have been based on standardizing existing implementations. There's nothing really new or extraordinary there.

What is kinda new is that CDI recently has been devolved to having only active committers from one implementation, which is Weld, participating. And that single implementation is not even represented fully, since of the aforementioned Quarkus importance.

If I'm not mistaken, representatives from OWB weren't present in any of the CDI calls from last year, and didn't participate in much of the issues / PRs either. That fact alone may have nudged CDI 4.0 strongly in the direction of Quarkus, since the Quarkus people were almost the only ones doing any pulling.

Kind regards,

Arjan Tijms

 

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