Le mar. 31 janv. 2023 à 09:31, Mark Struberg <strub...@yahoo.de.invalid> 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 <rmannibu...@gmail.com > >: > > > > Le lun. 30 janv. 2023 à 21:27, Mark Struberg <strub...@yahoo.de.invalid> > 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 <strub...@yahoo.de.invalid > >> <mailto:strub...@yahoo.de.invalid>> 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 <https://twitter.com/rmannibucau> | Blog > >>>>> <https://rmannibucau.metawerx.net/> | Old Blog > >>>>> <http://rmannibucau.wordpress.com> | Github < > >>>> https://github.com/rmannibucau> | > >>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | 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 > >>>>>> <strub...@yahoo.de.invalid>: > >>>>>> > >>>>>>> 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 > >> > >> > >
