Re: [DISCUSS] Release OWB-4.0.0?

[Jean-Louis MONTEIRO]

Agree with Romain

Good or bad it is there in the spec. We need something to pass the suite
before we can call it done and go final in my opinion.

I'm ok if it requires a flag or if it's in another separated module. But it
has to be there somehow.

Le lun. 30 janv. 2023, 14:48, Romain Manni-Bucau  a
écrit :

> * +1 to drop jetty plugin for now
> * +-0 to shade cdi-api (nobody will consume it anyway)
> * -1 to release to not milestone without being spec compliant - including
> cdi-lite which is part of cdi-core (even if we all disagree), minimum for
> me is to provide an openwebbeans-lite module implementing the cdi extension
> making it supported, +1 to get a 4.0.0-alpha1 if it helps
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le lun. 30 janv. 2023 à 14:43, Thomas Andraschko <
> andraschko.tho...@gmail.com> a écrit :
>
> > all sounds good to me
> >
> > Am Mo., 30. Jan. 2023 um 14:41 Uhr schrieb Mark Struberg
> > :
> >
> > > hi folks!
> > >
> > > We are up and running with passing most CDI-4.0 TCK tests.
> > > There are a few areas where we have excluded some tests:
> > >
> > > * CDI-lite. I'll not gonna implement this in OWB as it is purely for
> > > Quarkus and I don't care. It should be straight forward to implement
> the
> > > functionality as  OWB plugin if someone really needs it though.
> > > * Some challenged tests, some unspecified behaviour in some tests. E.g.
> > > they assume a specified order class annotations before method
> annotations
> > > for Interceptors. But the spec *explicitly* says that for Interceptors
> > with
> > > the same @Priority the order is unspecified.
> > > * backward incompatible reversing the default bean-discovery-mode for
> > > empty beans.xmls. I'll not gonna implement this as it also did break
> the
> > > JakartaEE rules alltogether.
> > >
> > >
> > > Things I want to change yet before the release:
> > >
> > > * Decide about the jetty9 plugin. Tbh I'd keep it excluded until
> someone
> > > wants to contribute fixes to it.
> > > * provide a shaded version of the CDI api jar without all the CDI-lite
> > > parts.
> > >
> > >
> > > Wdyt?
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > >
> >
>

Re: [DISCUSS] Release OWB-4.0.0?

[Mark Struberg]

I've created a few tickets but not all yet. Just wanted to get the most 
obviously broken tests out of the way.

LieGrue,
strub

> Am 09.02.2023 um 02:17 schrieb David Blevins :
> 
> 
> 
>> On Jan 30, 2023, at 5:40 AM, Mark Struberg  wrote:
>> * Some challenged tests, some unspecified behaviour in some tests. E.g. they 
>> assume a specified order class annotations before method annotations for 
>> Interceptors. But the spec *explicitly* says that for Interceptors with the 
>> same @Priority the order is unspecified.
> 
> Do you have links to the challenges you filed and does it look like they’ll 
> be accepted?
> 
> 
> -David
> 

Re: [DISCUSS] Release OWB-4.0.0?

[Mark Struberg]

I'm fine with 11 as well, all runs really well and we don't use any feature 
from Java17. I did it mainly to push the boundaries a bit. Maybe I pushed too 
far ;)

LieGrue,
strub


> Am 09.02.2023 um 02:15 schrieb David Blevins :
> 
> Looks like we’ve set the Java version to 17.  I can confirm it does build 
> fine with 11.
> 
> Are we open to using 11 for 4.0.0 and waiting till the next release to go to 
> 17?
> 
> 
> -David
> 
> 
>> On Jan 30, 2023, at 5:40 AM, Mark Struberg  wrote:
>> 
>> hi folks!
>> 
>> We are up and running with passing most CDI-4.0 TCK tests.
>> There are a few areas where we have excluded some tests:
>> 
>> * CDI-lite. I'll not gonna implement this in OWB as it is purely for Quarkus 
>> and I don't care. It should be straight forward to implement the 
>> functionality as  OWB plugin if someone really needs it though.
>> * Some challenged tests, some unspecified behaviour in some tests. E.g. they 
>> assume a specified order class annotations before method annotations for 
>> Interceptors. But the spec *explicitly* says that for Interceptors with the 
>> same @Priority the order is unspecified.
>> * backward incompatible reversing the default bean-discovery-mode for empty 
>> beans.xmls. I'll not gonna implement this as it also did break the JakartaEE 
>> rules alltogether.
>> 
>> 
>> Things I want to change yet before the release:
>> 
>> * Decide about the jetty9 plugin. Tbh I'd keep it excluded until someone 
>> wants to contribute fixes to it.
>> * provide a shaded version of the CDI api jar without all the CDI-lite parts.
>> 
>> 
>> Wdyt?
>> 
>> LieGrue,
>> strub
>> 
>> 
> 

Re: [DISCUSS] Release OWB-4.0.0?

[Romain Manni-Bucau]

For reference:

> The TCKs will be compiled at the Java SE 11 level. In order to allow for
runtimes beyond Java SE 11, the TCK will also need to be (successfully)
executed with Java SE 17.

> How a Compatible Implementation supports the Java SE 11 runtime (or
above) will be left as a vendor-defined solution.

>
https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee10/JakartaEE10ReleasePlanFAQ#why-require-java-se-17-for-tck-execution

Which means only java 17 is a requirement of the specs even if java 11 is
ok-ish. Have to admit this is a very weird writing and it looks like people
disagreed so everything was put in the specs to make everyone happy so the
spec does not cover the actual requirement.

However since spec jars are java 11 I think it is ok to relax the compiler
settings.

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



Le jeu. 9 févr. 2023 à 18:56, David Blevins  a
écrit :

> Both CDI 4.0 and the Jakarta EE Core/Webprofile/Platform specs all support
> Java 11 or higher in the spec and on the spec page.
>
>  - https://jakarta.ee/specifications/cdi/4.0/
>  - https://jakarta.ee/specifications/coreprofile/10/
>
>
> -David
>
> > On Feb 8, 2023, at 10:48 PM, Romain Manni-Bucau 
> wrote:
> >
> > Hi David,
> >
> > Guess 17 is a prerequisite of the spec so no real choice afaik until we
> > dont comply to the api.
> > For j11/cdi3 our previous shades do the job.
> >
> > Tck filters+jira links are in the testng xml config if it helps.
> >
> > Romain
> >
> > Le jeu. 9 févr. 2023 à 02:17, David Blevins  a
> > écrit :
> >
> >>
> >>
> >>> On Jan 30, 2023, at 5:40 AM, Mark Struberg 
> >> wrote:
> >>> * Some challenged tests, some unspecified behaviour in some tests. E.g.
> >> they assume a specified order class annotations before method
> annotations
> >> for Interceptors. But the spec *explicitly* says that for Interceptors
> with
> >> the same @Priority the order is unspecified.
> >>
> >> Do you have links to the challenges you filed and does it look like
> >> they’ll be accepted?
> >>
> >>
> >> -David
> >>
> >>
>
>

Re: [DISCUSS] Release OWB-4.0.0?

[David Blevins]

Both CDI 4.0 and the Jakarta EE Core/Webprofile/Platform specs all support Java 
11 or higher in the spec and on the spec page.

 - https://jakarta.ee/specifications/cdi/4.0/
 - https://jakarta.ee/specifications/coreprofile/10/


-David

> On Feb 8, 2023, at 10:48 PM, Romain Manni-Bucau  wrote:
> 
> Hi David,
> 
> Guess 17 is a prerequisite of the spec so no real choice afaik until we
> dont comply to the api.
> For j11/cdi3 our previous shades do the job.
> 
> Tck filters+jira links are in the testng xml config if it helps.
> 
> Romain
> 
> Le jeu. 9 févr. 2023 à 02:17, David Blevins  a
> écrit :
> 
>> 
>> 
>>> On Jan 30, 2023, at 5:40 AM, Mark Struberg 
>> wrote:
>>> * Some challenged tests, some unspecified behaviour in some tests. E.g.
>> they assume a specified order class annotations before method annotations
>> for Interceptors. But the spec *explicitly* says that for Interceptors with
>> the same @Priority the order is unspecified.
>> 
>> Do you have links to the challenges you filed and does it look like
>> they’ll be accepted?
>> 
>> 
>> -David
>> 
>> 

Re: [DISCUSS] Release OWB-4.0.0?

[Romain Manni-Bucau]

Hi David,

Guess 17 is a prerequisite of the spec so no real choice afaik until we
dont comply to the api.
For j11/cdi3 our previous shades do the job.

Tck filters+jira links are in the testng xml config if it helps.

Romain

Le jeu. 9 févr. 2023 à 02:17, David Blevins  a
écrit :

>
>
> > On Jan 30, 2023, at 5:40 AM, Mark Struberg 
> wrote:
> > * Some challenged tests, some unspecified behaviour in some tests. E.g.
> they assume a specified order class annotations before method annotations
> for Interceptors. But the spec *explicitly* says that for Interceptors with
> the same @Priority the order is unspecified.
>
> Do you have links to the challenges you filed and does it look like
> they’ll be accepted?
>
>
> -David
>
>

Re: [DISCUSS] Release OWB-4.0.0?

[David Blevins]

> On Jan 30, 2023, at 5:40 AM, Mark Struberg  wrote:
> * Some challenged tests, some unspecified behaviour in some tests. E.g. they 
> assume a specified order class annotations before method annotations for 
> Interceptors. But the spec *explicitly* says that for Interceptors with the 
> same @Priority the order is unspecified.

Do you have links to the challenges you filed and does it look like they’ll be 
accepted?


-David

Re: [DISCUSS] Release OWB-4.0.0?

[David Blevins]

Looks like we’ve set the Java version to 17.  I can confirm it does build fine 
with 11.

Are we open to using 11 for 4.0.0 and waiting till the next release to go to 17?


-David


> On Jan 30, 2023, at 5:40 AM, Mark Struberg  wrote:
> 
> hi folks!
> 
> We are up and running with passing most CDI-4.0 TCK tests.
> There are a few areas where we have excluded some tests:
> 
> * CDI-lite. I'll not gonna implement this in OWB as it is purely for Quarkus 
> and I don't care. It should be straight forward to implement the 
> functionality as  OWB plugin if someone really needs it though.
> * Some challenged tests, some unspecified behaviour in some tests. E.g. they 
> assume a specified order class annotations before method annotations for 
> Interceptors. But the spec *explicitly* says that for Interceptors with the 
> same @Priority the order is unspecified.
> * backward incompatible reversing the default bean-discovery-mode for empty 
> beans.xmls. I'll not gonna implement this as it also did break the JakartaEE 
> rules alltogether.
> 
> 
> Things I want to change yet before the release:
> 
> * Decide about the jetty9 plugin. Tbh I'd keep it excluded until someone 
> wants to contribute fixes to it.
> * provide a shaded version of the CDI api jar without all the CDI-lite parts.
> 
> 
> Wdyt?
> 
> LieGrue,
> strub
> 
> 

Re: [DISCUSS] Release OWB-4.0.0?

[Romain Manni-Bucau]

Le mar. 31 janv. 2023 à 09:31, Mark Struberg  a
écrit :

> Already in the past we did not implement all features of the CDI spec in
> OWB. We left certain EE features defined in the CDI spec up to OpenEJB for
> example.What we did is to provide internal SPI to make this possible. As we
> do now. Imo all the necessary SPI should be in place. If something is
> missing I gonna add it. But I personally will not invest time in CDI-light.
> If you or anyone else wants to do it you are perfectly welcome. But I
> personally will not like to see us blocked for years to come by a trojan
> horse feature of imo not much use.
>

Please don't mix things up Mark:

1. You don't want to impl it -> once again it is more than fine, no issue,
2. OWB targets CDI standalone and servlet, nothing more but unfortunately
CDI lite is part of any CDI scope so we have to cover it, no SPI needed (it
is mainly a CDI extension) but must be supported OOTB to be a final release,
3. Nothing is blocked once again, doing an pre-release does not block
anything, just reflect the status of the project.

If we want to do a final which does not target CDI (current main) we have
to:

1. change the project scope and communicate about it
2. find a way to create our own API without ambiguity on jakarta one
3. find a way to validate applications at build time

3 can be a maven plugin to start, 1 is a matter of doing the homework and
waiting ~2months, 2 is almost impossible and failed each time it got tried
(our resource module, quarkus, ).
So I really think it would deserve the project to fake we are CDI 4 in our
releases.


>
> LieGrue,
> strub
>
>
> > Am 30.01.2023 um 23:23 schrieb Romain Manni-Bucau  >:
> >
> > Le lun. 30 janv. 2023 à 21:27, Mark Struberg 
> a
> > écrit :
> >
> >> It's not the full story.
> >> We for example did never really implement the inconsistent BDA
> >> specification, global alternatives etc.
> >> Same here.
> >>
> >
> > But we implemented all api, here it is way more obvious it is wrong since
> > it is having CDI core dead api, nothing ambiguous as the bda so not the
> > same story at all IMHO.
> >
> >
> >> The CDI-4.0 situation is an inconsistent mess. Even Weld does not
> >> implement it fully it seems.
> >> I really don't want to be blocked by a mess in the spec.
> >>
> >
> > Strictly speaking it was a stupid spec decision but it is not a mess.
> > Make it optional, yes, but not missing in a final release targetting this
> > spec version. Literally means project goal we write on each report would
> > either be totally wrong or we freeze the project to jakartaee 9.
> >
> > Both are wrong IMHO on the community+project sides.
> >
> >
> >> LieGrue,
> >> strub
> >>
> >>
> >>
> >>> Am 30.01.2023 um 19:02 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> >>> :
> >>>
> >>> Le lun. 30 janv. 2023 à 17:10, Mark Struberg  >> > a
> >>> écrit :
> >>>
>  I don't see any reason for any -alpha or whatever release. We did
> never
>  claim to be a certified implementation in the past, nor likely will we
> >> in
>  the future. We try to pass as much from the TCK as makes sense and
>  report/challenge TCK tests which disrespect/contradict the spec
> wording
>  and/or JavaDoc of the API. Most of those challenge tickets have been
>  bulk-closed and never really addressed for the past CDI versions. So
> my
>  will to go hunt for the carrot in front of my nose is not infinite
>  ("endenwollend" as we say here in Vienna).
> 
> >>>
> >>> We always went the spec side even if we add toggles to disable/enable
> >>> things, but ultimately we cover the full API.
> >>> Not providing any way to get it means we don't implement CDI anymore,
> >>> nothing else. Can be fine but should be promoted and we should also see
> >>> with TomEE what it means for them.
> >>> Holding a release is not a goal but doing a final which looks like it
> >>> covers the spec whereas it does not cover a third of it would be way
> more
> >>> negative for the project IMHO so let's not be the bad guys and just
> >> expose
> >>> explicitly our state with a pre-final whatever name fits for you.
> >>>
> >>>
> 
>  If someone wants to address/implement the CDI-lite functionality (s)he
> >> is
>  perfectly welcome to do so. I doubt I will find the time to do it.
> 
> >>>
> >>> Once again, no issue to not do it now, should just be a goal of 4.0.0.
> >>>
> >>>
> 
> 
>  LieGrue,
>  strub
> 
> > Am 30.01.2023 um 14:48 schrieb Romain Manni-Bucau <
> >> rmannibu...@gmail.com
> > :
> >
> > * +1 to drop jetty plugin for now
> > * +-0 to shade cdi-api (nobody will consume it anyway)
> > * -1 to release to not milestone without being spec compliant -
> >> including
> > cdi-lite which is part of cdi-core (even if we all disagree), minimum
> >> for
> > me is to provide an openwebbeans-lite module implementing the cdi
>  extension
> > making it 

Re: [DISCUSS] Release OWB-4.0.0?

[Mark Struberg]

Already in the past we did not implement all features of the CDI spec in OWB. 
We left certain EE features defined in the CDI spec up to OpenEJB for 
example.What we did is to provide internal SPI to make this possible. As we do 
now. Imo all the necessary SPI should be in place. If something is missing I 
gonna add it. But I personally will not invest time in CDI-light. If you or 
anyone else wants to do it you are perfectly welcome. But I personally will not 
like to see us blocked for years to come by a trojan horse feature of imo not 
much use.

LieGrue,
strub


> Am 30.01.2023 um 23:23 schrieb Romain Manni-Bucau :
> 
> Le lun. 30 janv. 2023 à 21:27, Mark Struberg  a
> écrit :
> 
>> It's not the full story.
>> We for example did never really implement the inconsistent BDA
>> specification, global alternatives etc.
>> Same here.
>> 
> 
> But we implemented all api, here it is way more obvious it is wrong since
> it is having CDI core dead api, nothing ambiguous as the bda so not the
> same story at all IMHO.
> 
> 
>> The CDI-4.0 situation is an inconsistent mess. Even Weld does not
>> implement it fully it seems.
>> I really don't want to be blocked by a mess in the spec.
>> 
> 
> Strictly speaking it was a stupid spec decision but it is not a mess.
> Make it optional, yes, but not missing in a final release targetting this
> spec version. Literally means project goal we write on each report would
> either be totally wrong or we freeze the project to jakartaee 9.
> 
> Both are wrong IMHO on the community+project sides.
> 
> 
>> LieGrue,
>> strub
>> 
>> 
>> 
>>> Am 30.01.2023 um 19:02 schrieb Romain Manni-Bucau >> :
>>> 
>>> Le lun. 30 janv. 2023 à 17:10, Mark Struberg > > a
>>> écrit :
>>> 
 I don't see any reason for any -alpha or whatever release. We did never
 claim to be a certified implementation in the past, nor likely will we
>> in
 the future. We try to pass as much from the TCK as makes sense and
 report/challenge TCK tests which disrespect/contradict the spec wording
 and/or JavaDoc of the API. Most of those challenge tickets have been
 bulk-closed and never really addressed for the past CDI versions. So my
 will to go hunt for the carrot in front of my nose is not infinite
 ("endenwollend" as we say here in Vienna).
 
>>> 
>>> We always went the spec side even if we add toggles to disable/enable
>>> things, but ultimately we cover the full API.
>>> Not providing any way to get it means we don't implement CDI anymore,
>>> nothing else. Can be fine but should be promoted and we should also see
>>> with TomEE what it means for them.
>>> Holding a release is not a goal but doing a final which looks like it
>>> covers the spec whereas it does not cover a third of it would be way more
>>> negative for the project IMHO so let's not be the bad guys and just
>> expose
>>> explicitly our state with a pre-final whatever name fits for you.
>>> 
>>> 
 
 If someone wants to address/implement the CDI-lite functionality (s)he
>> is
 perfectly welcome to do so. I doubt I will find the time to do it.
 
>>> 
>>> Once again, no issue to not do it now, should just be a goal of 4.0.0.
>>> 
>>> 
 
 
 LieGrue,
 strub
 
> Am 30.01.2023 um 14:48 schrieb Romain Manni-Bucau <
>> rmannibu...@gmail.com
> :
> 
> * +1 to drop jetty plugin for now
> * +-0 to shade cdi-api (nobody will consume it anyway)
> * -1 to release to not milestone without being spec compliant -
>> including
> cdi-lite which is part of cdi-core (even if we all disagree), minimum
>> for
> me is to provide an openwebbeans-lite module implementing the cdi
 extension
> making it supported, +1 to get a 4.0.0-alpha1 if it helps
> 
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
 https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
 
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
> 
> 
> 
> Le lun. 30 janv. 2023 à 14:43, Thomas Andraschko <
> andraschko.tho...@gmail.com> a écrit :
> 
>> all sounds good to me
>> 
>> Am Mo., 30. Jan. 2023 um 14:41 Uhr schrieb Mark Struberg
>> :
>> 
>>> hi folks!
>>> 
>>> We are up and running with passing most CDI-4.0 TCK tests.
>>> There are a few areas where we have excluded some tests:
>>> 
>>> * CDI-lite. I'll not gonna implement this in OWB as it is purely for
>>> Quarkus and I don't care. It should be straight forward to implement
 the
>>> functionality as  OWB plugin if someone really needs it though.
>>> * Some challenged tests, some unspecified behaviour in some tests.
>> E.g.
>>> they assume a specified order class annotations before method
 

Re: [DISCUSS] Release OWB-4.0.0?

[Romain Manni-Bucau]

Le lun. 30 janv. 2023 à 21:27, Mark Struberg  a
écrit :

> It's not the full story.
> We for example did never really implement the inconsistent BDA
> specification, global alternatives etc.
> Same here.
>

But we implemented all api, here it is way more obvious it is wrong since
it is having CDI core dead api, nothing ambiguous as the bda so not the
same story at all IMHO.


> The CDI-4.0 situation is an inconsistent mess. Even Weld does not
> implement it fully it seems.
> I really don't want to be blocked by a mess in the spec.
>

Strictly speaking it was a stupid spec decision but it is not a mess.
Make it optional, yes, but not missing in a final release targetting this
spec version. Literally means project goal we write on each report would
either be totally wrong or we freeze the project to jakartaee 9.

Both are wrong IMHO on the community+project sides.


> LieGrue,
> strub
>
>
>
> > Am 30.01.2023 um 19:02 schrieb Romain Manni-Bucau  >:
> >
> > Le lun. 30 janv. 2023 à 17:10, Mark Struberg  > a
> > écrit :
> >
> >> I don't see any reason for any -alpha or whatever release. We did never
> >> claim to be a certified implementation in the past, nor likely will we
> in
> >> the future. We try to pass as much from the TCK as makes sense and
> >> report/challenge TCK tests which disrespect/contradict the spec wording
> >> and/or JavaDoc of the API. Most of those challenge tickets have been
> >> bulk-closed and never really addressed for the past CDI versions. So my
> >> will to go hunt for the carrot in front of my nose is not infinite
> >> ("endenwollend" as we say here in Vienna).
> >>
> >
> > We always went the spec side even if we add toggles to disable/enable
> > things, but ultimately we cover the full API.
> > Not providing any way to get it means we don't implement CDI anymore,
> > nothing else. Can be fine but should be promoted and we should also see
> > with TomEE what it means for them.
> > Holding a release is not a goal but doing a final which looks like it
> > covers the spec whereas it does not cover a third of it would be way more
> > negative for the project IMHO so let's not be the bad guys and just
> expose
> > explicitly our state with a pre-final whatever name fits for you.
> >
> >
> >>
> >> If someone wants to address/implement the CDI-lite functionality (s)he
> is
> >> perfectly welcome to do so. I doubt I will find the time to do it.
> >>
> >
> > Once again, no issue to not do it now, should just be a goal of 4.0.0.
> >
> >
> >>
> >>
> >> LieGrue,
> >> strub
> >>
> >>> Am 30.01.2023 um 14:48 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> >>> :
> >>>
> >>> * +1 to drop jetty plugin for now
> >>> * +-0 to shade cdi-api (nobody will consume it anyway)
> >>> * -1 to release to not milestone without being spec compliant -
> including
> >>> cdi-lite which is part of cdi-core (even if we all disagree), minimum
> for
> >>> me is to provide an openwebbeans-lite module implementing the cdi
> >> extension
> >>> making it supported, +1 to get a 4.0.0-alpha1 if it helps
> >>>
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau  |  Blog
> >>>  | Old Blog
> >>>  | Github <
> >> https://github.com/rmannibucau> |
> >>> LinkedIn  | Book
> >>> <
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >>>
> >>>
> >>>
> >>> Le lun. 30 janv. 2023 à 14:43, Thomas Andraschko <
> >>> andraschko.tho...@gmail.com> a écrit :
> >>>
>  all sounds good to me
> 
>  Am Mo., 30. Jan. 2023 um 14:41 Uhr schrieb Mark Struberg
>  :
> 
> > hi folks!
> >
> > We are up and running with passing most CDI-4.0 TCK tests.
> > There are a few areas where we have excluded some tests:
> >
> > * CDI-lite. I'll not gonna implement this in OWB as it is purely for
> > Quarkus and I don't care. It should be straight forward to implement
> >> the
> > functionality as  OWB plugin if someone really needs it though.
> > * Some challenged tests, some unspecified behaviour in some tests.
> E.g.
> > they assume a specified order class annotations before method
> >> annotations
> > for Interceptors. But the spec *explicitly* says that for
> Interceptors
>  with
> > the same @Priority the order is unspecified.
> > * backward incompatible reversing the default bean-discovery-mode for
> > empty beans.xmls. I'll not gonna implement this as it also did break
> >> the
> > JakartaEE rules alltogether.
> >
> >
> > Things I want to change yet before the release:
> >
> > * Decide about the jetty9 plugin. Tbh I'd keep it excluded until
> >> someone
> > wants to contribute fixes to it.
> > * provide a shaded version of the CDI api jar without all the
> CDI-lite
> > parts.
> >
> >
> > Wdyt?
> >
> > LieGrue,
> 

Re: [DISCUSS] Release OWB-4.0.0?

[Mark Struberg]

It's not the full story. 
We for example did never really implement the inconsistent BDA specification, 
global alternatives etc. 
Same here.

The CDI-4.0 situation is an inconsistent mess. Even Weld does not implement it 
fully it seems.
I really don't want to be blocked by a mess in the spec.

LieGrue,
strub



> Am 30.01.2023 um 19:02 schrieb Romain Manni-Bucau :
> 
> Le lun. 30 janv. 2023 à 17:10, Mark Struberg  > a
> écrit :
> 
>> I don't see any reason for any -alpha or whatever release. We did never
>> claim to be a certified implementation in the past, nor likely will we in
>> the future. We try to pass as much from the TCK as makes sense and
>> report/challenge TCK tests which disrespect/contradict the spec wording
>> and/or JavaDoc of the API. Most of those challenge tickets have been
>> bulk-closed and never really addressed for the past CDI versions. So my
>> will to go hunt for the carrot in front of my nose is not infinite
>> ("endenwollend" as we say here in Vienna).
>> 
> 
> We always went the spec side even if we add toggles to disable/enable
> things, but ultimately we cover the full API.
> Not providing any way to get it means we don't implement CDI anymore,
> nothing else. Can be fine but should be promoted and we should also see
> with TomEE what it means for them.
> Holding a release is not a goal but doing a final which looks like it
> covers the spec whereas it does not cover a third of it would be way more
> negative for the project IMHO so let's not be the bad guys and just expose
> explicitly our state with a pre-final whatever name fits for you.
> 
> 
>> 
>> If someone wants to address/implement the CDI-lite functionality (s)he is
>> perfectly welcome to do so. I doubt I will find the time to do it.
>> 
> 
> Once again, no issue to not do it now, should just be a goal of 4.0.0.
> 
> 
>> 
>> 
>> LieGrue,
>> strub
>> 
>>> Am 30.01.2023 um 14:48 schrieb Romain Manni-Bucau >> :
>>> 
>>> * +1 to drop jetty plugin for now
>>> * +-0 to shade cdi-api (nobody will consume it anyway)
>>> * -1 to release to not milestone without being spec compliant - including
>>> cdi-lite which is part of cdi-core (even if we all disagree), minimum for
>>> me is to provide an openwebbeans-lite module implementing the cdi
>> extension
>>> making it supported, +1 to get a 4.0.0-alpha1 if it helps
>>> 
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau  |  Blog
>>>  | Old Blog
>>>  | Github <
>> https://github.com/rmannibucau> |
>>> LinkedIn  | Book
>>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> 
>>> 
>>> 
>>> Le lun. 30 janv. 2023 à 14:43, Thomas Andraschko <
>>> andraschko.tho...@gmail.com> a écrit :
>>> 
 all sounds good to me
 
 Am Mo., 30. Jan. 2023 um 14:41 Uhr schrieb Mark Struberg
 :
 
> hi folks!
> 
> We are up and running with passing most CDI-4.0 TCK tests.
> There are a few areas where we have excluded some tests:
> 
> * CDI-lite. I'll not gonna implement this in OWB as it is purely for
> Quarkus and I don't care. It should be straight forward to implement
>> the
> functionality as  OWB plugin if someone really needs it though.
> * Some challenged tests, some unspecified behaviour in some tests. E.g.
> they assume a specified order class annotations before method
>> annotations
> for Interceptors. But the spec *explicitly* says that for Interceptors
 with
> the same @Priority the order is unspecified.
> * backward incompatible reversing the default bean-discovery-mode for
> empty beans.xmls. I'll not gonna implement this as it also did break
>> the
> JakartaEE rules alltogether.
> 
> 
> Things I want to change yet before the release:
> 
> * Decide about the jetty9 plugin. Tbh I'd keep it excluded until
>> someone
> wants to contribute fixes to it.
> * provide a shaded version of the CDI api jar without all the CDI-lite
> parts.
> 
> 
> Wdyt?
> 
> LieGrue,
> strub

Re: [DISCUSS] Release OWB-4.0.0?

[Romain Manni-Bucau]

Le lun. 30 janv. 2023 à 17:10, Mark Struberg  a
écrit :

> I don't see any reason for any -alpha or whatever release. We did never
> claim to be a certified implementation in the past, nor likely will we in
> the future. We try to pass as much from the TCK as makes sense and
> report/challenge TCK tests which disrespect/contradict the spec wording
> and/or JavaDoc of the API. Most of those challenge tickets have been
> bulk-closed and never really addressed for the past CDI versions. So my
> will to go hunt for the carrot in front of my nose is not infinite
> ("endenwollend" as we say here in Vienna).
>

We always went the spec side even if we add toggles to disable/enable
things, but ultimately we cover the full API.
Not providing any way to get it means we don't implement CDI anymore,
nothing else. Can be fine but should be promoted and we should also see
with TomEE what it means for them.
Holding a release is not a goal but doing a final which looks like it
covers the spec whereas it does not cover a third of it would be way more
negative for the project IMHO so let's not be the bad guys and just expose
explicitly our state with a pre-final whatever name fits for you.


>
> If someone wants to address/implement the CDI-lite functionality (s)he is
> perfectly welcome to do so. I doubt I will find the time to do it.
>

Once again, no issue to not do it now, should just be a goal of 4.0.0.


>
>
> LieGrue,
> strub
>
> > Am 30.01.2023 um 14:48 schrieb Romain Manni-Bucau  >:
> >
> > * +1 to drop jetty plugin for now
> > * +-0 to shade cdi-api (nobody will consume it anyway)
> > * -1 to release to not milestone without being spec compliant - including
> > cdi-lite which is part of cdi-core (even if we all disagree), minimum for
> > me is to provide an openwebbeans-lite module implementing the cdi
> extension
> > making it supported, +1 to get a 4.0.0-alpha1 if it helps
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le lun. 30 janv. 2023 à 14:43, Thomas Andraschko <
> > andraschko.tho...@gmail.com> a écrit :
> >
> >> all sounds good to me
> >>
> >> Am Mo., 30. Jan. 2023 um 14:41 Uhr schrieb Mark Struberg
> >> :
> >>
> >>> hi folks!
> >>>
> >>> We are up and running with passing most CDI-4.0 TCK tests.
> >>> There are a few areas where we have excluded some tests:
> >>>
> >>> * CDI-lite. I'll not gonna implement this in OWB as it is purely for
> >>> Quarkus and I don't care. It should be straight forward to implement
> the
> >>> functionality as  OWB plugin if someone really needs it though.
> >>> * Some challenged tests, some unspecified behaviour in some tests. E.g.
> >>> they assume a specified order class annotations before method
> annotations
> >>> for Interceptors. But the spec *explicitly* says that for Interceptors
> >> with
> >>> the same @Priority the order is unspecified.
> >>> * backward incompatible reversing the default bean-discovery-mode for
> >>> empty beans.xmls. I'll not gonna implement this as it also did break
> the
> >>> JakartaEE rules alltogether.
> >>>
> >>>
> >>> Things I want to change yet before the release:
> >>>
> >>> * Decide about the jetty9 plugin. Tbh I'd keep it excluded until
> someone
> >>> wants to contribute fixes to it.
> >>> * provide a shaded version of the CDI api jar without all the CDI-lite
> >>> parts.
> >>>
> >>>
> >>> Wdyt?
> >>>
> >>> LieGrue,
> >>> strub
> >>>
> >>>
> >>>
> >>
>
>

Re: [DISCUSS] Release OWB-4.0.0?

[Mark Struberg]

I don't see any reason for any -alpha or whatever release. We did never claim 
to be a certified implementation in the past, nor likely will we in the future. 
We try to pass as much from the TCK as makes sense and report/challenge TCK 
tests which disrespect/contradict the spec wording and/or JavaDoc of the API. 
Most of those challenge tickets have been bulk-closed and never really 
addressed for the past CDI versions. So my will to go hunt for the carrot in 
front of my nose is not infinite ("endenwollend" as we say here in Vienna).

If someone wants to address/implement the CDI-lite functionality (s)he is 
perfectly welcome to do so. I doubt I will find the time to do it.


LieGrue,
strub

> Am 30.01.2023 um 14:48 schrieb Romain Manni-Bucau :
> 
> * +1 to drop jetty plugin for now
> * +-0 to shade cdi-api (nobody will consume it anyway)
> * -1 to release to not milestone without being spec compliant - including
> cdi-lite which is part of cdi-core (even if we all disagree), minimum for
> me is to provide an openwebbeans-lite module implementing the cdi extension
> making it supported, +1 to get a 4.0.0-alpha1 if it helps
> 
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
> 
> 
> Le lun. 30 janv. 2023 à 14:43, Thomas Andraschko <
> andraschko.tho...@gmail.com> a écrit :
> 
>> all sounds good to me
>> 
>> Am Mo., 30. Jan. 2023 um 14:41 Uhr schrieb Mark Struberg
>> :
>> 
>>> hi folks!
>>> 
>>> We are up and running with passing most CDI-4.0 TCK tests.
>>> There are a few areas where we have excluded some tests:
>>> 
>>> * CDI-lite. I'll not gonna implement this in OWB as it is purely for
>>> Quarkus and I don't care. It should be straight forward to implement the
>>> functionality as  OWB plugin if someone really needs it though.
>>> * Some challenged tests, some unspecified behaviour in some tests. E.g.
>>> they assume a specified order class annotations before method annotations
>>> for Interceptors. But the spec *explicitly* says that for Interceptors
>> with
>>> the same @Priority the order is unspecified.
>>> * backward incompatible reversing the default bean-discovery-mode for
>>> empty beans.xmls. I'll not gonna implement this as it also did break the
>>> JakartaEE rules alltogether.
>>> 
>>> 
>>> Things I want to change yet before the release:
>>> 
>>> * Decide about the jetty9 plugin. Tbh I'd keep it excluded until someone
>>> wants to contribute fixes to it.
>>> * provide a shaded version of the CDI api jar without all the CDI-lite
>>> parts.
>>> 
>>> 
>>> Wdyt?
>>> 
>>> LieGrue,
>>> strub
>>> 
>>> 
>>> 
>> 

Re: [DISCUSS] Release OWB-4.0.0?

[Romain Manni-Bucau]

* +1 to drop jetty plugin for now
* +-0 to shade cdi-api (nobody will consume it anyway)
* -1 to release to not milestone without being spec compliant - including
cdi-lite which is part of cdi-core (even if we all disagree), minimum for
me is to provide an openwebbeans-lite module implementing the cdi extension
making it supported, +1 to get a 4.0.0-alpha1 if it helps


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



Le lun. 30 janv. 2023 à 14:43, Thomas Andraschko <
andraschko.tho...@gmail.com> a écrit :

> all sounds good to me
>
> Am Mo., 30. Jan. 2023 um 14:41 Uhr schrieb Mark Struberg
> :
>
> > hi folks!
> >
> > We are up and running with passing most CDI-4.0 TCK tests.
> > There are a few areas where we have excluded some tests:
> >
> > * CDI-lite. I'll not gonna implement this in OWB as it is purely for
> > Quarkus and I don't care. It should be straight forward to implement the
> > functionality as  OWB plugin if someone really needs it though.
> > * Some challenged tests, some unspecified behaviour in some tests. E.g.
> > they assume a specified order class annotations before method annotations
> > for Interceptors. But the spec *explicitly* says that for Interceptors
> with
> > the same @Priority the order is unspecified.
> > * backward incompatible reversing the default bean-discovery-mode for
> > empty beans.xmls. I'll not gonna implement this as it also did break the
> > JakartaEE rules alltogether.
> >
> >
> > Things I want to change yet before the release:
> >
> > * Decide about the jetty9 plugin. Tbh I'd keep it excluded until someone
> > wants to contribute fixes to it.
> > * provide a shaded version of the CDI api jar without all the CDI-lite
> > parts.
> >
> >
> > Wdyt?
> >
> > LieGrue,
> > strub
> >
> >
> >
>

Re: [DISCUSS] Release OWB-4.0.0?

[Daniel Dias Dos Santos]

Hi,

It's good for me too.

On Mon, Jan 30, 2023, 10:43 Thomas Andraschko 
wrote:

> all sounds good to me
>
> Am Mo., 30. Jan. 2023 um 14:41 Uhr schrieb Mark Struberg
> :
>
> > hi folks!
> >
> > We are up and running with passing most CDI-4.0 TCK tests.
> > There are a few areas where we have excluded some tests:
> >
> > * CDI-lite. I'll not gonna implement this in OWB as it is purely for
> > Quarkus and I don't care. It should be straight forward to implement the
> > functionality as  OWB plugin if someone really needs it though.
> > * Some challenged tests, some unspecified behaviour in some tests. E.g.
> > they assume a specified order class annotations before method annotations
> > for Interceptors. But the spec *explicitly* says that for Interceptors
> with
> > the same @Priority the order is unspecified.
> > * backward incompatible reversing the default bean-discovery-mode for
> > empty beans.xmls. I'll not gonna implement this as it also did break the
> > JakartaEE rules alltogether.
> >
> >
> > Things I want to change yet before the release:
> >
> > * Decide about the jetty9 plugin. Tbh I'd keep it excluded until someone
> > wants to contribute fixes to it.
> > * provide a shaded version of the CDI api jar without all the CDI-lite
> > parts.
> >
> >
> > Wdyt?
> >
> > LieGrue,
> > strub
> >
> >
> >
>

Re: [DISCUSS] Release OWB-4.0.0?

[Thomas Andraschko]

all sounds good to me

Am Mo., 30. Jan. 2023 um 14:41 Uhr schrieb Mark Struberg
:

> hi folks!
>
> We are up and running with passing most CDI-4.0 TCK tests.
> There are a few areas where we have excluded some tests:
>
> * CDI-lite. I'll not gonna implement this in OWB as it is purely for
> Quarkus and I don't care. It should be straight forward to implement the
> functionality as  OWB plugin if someone really needs it though.
> * Some challenged tests, some unspecified behaviour in some tests. E.g.
> they assume a specified order class annotations before method annotations
> for Interceptors. But the spec *explicitly* says that for Interceptors with
> the same @Priority the order is unspecified.
> * backward incompatible reversing the default bean-discovery-mode for
> empty beans.xmls. I'll not gonna implement this as it also did break the
> JakartaEE rules alltogether.
>
>
> Things I want to change yet before the release:
>
> * Decide about the jetty9 plugin. Tbh I'd keep it excluded until someone
> wants to contribute fixes to it.
> * provide a shaded version of the CDI api jar without all the CDI-lite
> parts.
>
>
> Wdyt?
>
> LieGrue,
> strub
>
>
>

[DISCUSS] Release OWB-4.0.0?

[Mark Struberg]

hi folks!

We are up and running with passing most CDI-4.0 TCK tests.
There are a few areas where we have excluded some tests:

* CDI-lite. I'll not gonna implement this in OWB as it is purely for Quarkus 
and I don't care. It should be straight forward to implement the functionality 
as  OWB plugin if someone really needs it though.
* Some challenged tests, some unspecified behaviour in some tests. E.g. they 
assume a specified order class annotations before method annotations for 
Interceptors. But the spec *explicitly* says that for Interceptors with the 
same @Priority the order is unspecified.
* backward incompatible reversing the default bean-discovery-mode for empty 
beans.xmls. I'll not gonna implement this as it also did break the JakartaEE 
rules alltogether.


Things I want to change yet before the release:

* Decide about the jetty9 plugin. Tbh I'd keep it excluded until someone wants 
to contribute fixes to it.
* provide a shaded version of the CDI api jar without all the CDI-lite parts.


Wdyt?

LieGrue,
strub