Re: [DISCUSS] CDI Compliance and breaking changes

[Romain Manni-Bucau]

Hi,

Think there are multiple points there and we should absolutely avoid a
compliance flag in owb-core/se modules until it is requires and we ack the
change.
For other changes (the one we dont want, we can just use our spi mecanism
and change the behavior in an owb-compliancy module maybe.

For me the points are:

* Did the spec broke something for good -> add a toggle
* Did the spec broke without reason -> need to check if intended, if so
compliancy module else ignore
* Is the spec clear about the impl it expects (for ex it is not for
container events) -> if yes then impl else discuss and if no compromise
then compliancy module

Side note: if the toggle is a one liner the compliancy module just enables
it in openwebbeans.properties, no need to split the impl in multiple parts
or add a SPI if simple.

Overall my fear right now is core become bloated because each version of
the spec adds what is already there but in a new package or way so I hope
we can keep a core light and be compliant in a module marked as "they did
it wrong but you can get it too".

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 27 févr. 2023 à 20:58, Jean-Louis Monteiro 
a écrit :

> Hello guys,
>
> I've been spending a couple of days trying to figure out what the spec says
> or does not. I also looked at the TCK tests we currently do not pass as
> well as what OWB/Weld do in both situations. I've also augmented the TCK
> tests to understand and test some other edge cases.
>
> *Important note*: I created a couple of challenges already and PRs to fix
> the spec/TCK and I'm happy to create more challenges. Mind that the process
> to create challenges is very well defined
> https://jakarta.ee/committees/specification/tckprocess/
>
> In essence, a challenge cannot be filed if we don't agree with the spec or
> if the spec is stupid, or else. We can only fill a challenge, if the TCK
> does not match something in the spec, if it's more restrictive, etc.
>
> << Good or bad, the spec is as it is now. The past/future does not matter
> >>
>
> I'm not sure about the history and if the spec evolved in the past and we
> did not follow, or if the spec introduced things we did not agree on and
> decided to not implement. As of now, we need changes if we want to ever be
> compliant.
>
> I'd like to discuss how to handle the breaking changes. I do think if we
> claim to implement CDI we must implement it all and correctly.
>
> I'm ok if we have a "compliance" flag if we don't want to break backward
> compatibility. But to me, it's a major version and jakarta namespace is
> already a huge backward compatibility issue. So for sure it's preferred we
> catch up with all breaking changes now and participate in the spec so we
> avoid future backward compatibility issues. If we don't do it now, of
> course it will be harder to do it later for our users and it means we'll
> never be able to claim compliance.
>
> It is obviously not a vote. But I think it's an important discussion.
> What do you think?
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>

[DISCUSS] CDI Compliance and breaking changes

[Jean-Louis Monteiro]

Hello guys,

I've been spending a couple of days trying to figure out what the spec says
or does not. I also looked at the TCK tests we currently do not pass as
well as what OWB/Weld do in both situations. I've also augmented the TCK
tests to understand and test some other edge cases.

*Important note*: I created a couple of challenges already and PRs to fix
the spec/TCK and I'm happy to create more challenges. Mind that the process
to create challenges is very well defined
https://jakarta.ee/committees/specification/tckprocess/

In essence, a challenge cannot be filed if we don't agree with the spec or
if the spec is stupid, or else. We can only fill a challenge, if the TCK
does not match something in the spec, if it's more restrictive, etc.

<< Good or bad, the spec is as it is now. The past/future does not matter >>

I'm not sure about the history and if the spec evolved in the past and we
did not follow, or if the spec introduced things we did not agree on and
decided to not implement. As of now, we need changes if we want to ever be
compliant.

I'd like to discuss how to handle the breaking changes. I do think if we
claim to implement CDI we must implement it all and correctly.

I'm ok if we have a "compliance" flag if we don't want to break backward
compatibility. But to me, it's a major version and jakarta namespace is
already a huge backward compatibility issue. So for sure it's preferred we
catch up with all breaking changes now and participate in the spec so we
avoid future backward compatibility issues. If we don't do it now, of
course it will be harder to do it later for our users and it means we'll
never be able to claim compliance.

It is obviously not a vote. But I think it's an important discussion.
What do you think?


--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com