Le mer. 23 nov. 2022 à 10:58, Mark Struberg via dev <dev@geronimo.apache.org> a écrit :
> As written over at the OWB list: > > I intend only to update OWB to the jakarta package names plus implement > the core changes. > > All that 'cdi-light' stuff (which is imo rather broken) is technically > optional and can also get implemented as a plugin. > Not from a spec standpoint, it is the opposite, full is optional but is based on lite (once again not saying it is good). > I just don't want to have all those tons of new classes around nobody > needs if not running on Quarkus. > Well, if you look the way the spec was written, then you need it. Or said otherwise, if you think this way you must make all the extension API optional as well and get "cdi-runtime-api", "cdi-lite", "cdi-full" or something like that. Once again I don't think we can fight much there so guess we should just get it as in the spec, optionally we can get as the spec intend lite bundle and full bundle but not the other way around. > > What about the other spec APIs we still need? use the Eclipse one (EPL + > spec)? What legal consequences does this have in comparison to updating our > own packages? It's mostly just package renames for now anyway. > Legally we are now fine to consumme jakarta artifacts so last time we discussed it we decided to keep our "forks" for OSGi but guess we can discuss with karaf/smix projects to drop it and let them do it if you want to stop doing spec jars. Just want we clearly document it for users on our website. > > LieGrue, > strub > > Am 23.11.2022 um 09:01 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>: > > Hi, > > Well, I guess the OSGi stuff is still a good justification to roll our own > even if they didnt catch up yet jakarta - think they will anyway and owb > runs in any case. > > On the flavor we can do a lite-free module but since standard version > assumes lite extensions are ran as part of the runtime - strictly speaking > they say runtime or build or anything but spec only defines a runtime so it > is literally at runtime - I guess owb still needs to impl it and I don't > like much the idea to implement a subpart of the minimum requirement of the > spec - never said I think what they did is ok, it is fully wrong but it is > what we have today and fighting against the spec is never good while using > its API IMHO. > > So concretely I would just do a standard bundle for OSGi stuff and be it. > We need to see what we do at OWB but fear we just back lite by a full > extensions at some point, at least in extension mode. > > 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 mar. 22 nov. 2022 à 23:52, Mark Struberg via dev < > dev@geronimo.apache.org> a écrit : > >> Hi! >> >> How do we want to approach the CDI-4.0 api? >> I don't want to just use the official API as it is bloated with the 'CDI >> light' stuff. >> So there is good reason to just keep our own version - even if it is just >> a shaded/spit of the official one. >> >> What about the others? Do we still want to roll our own or also take the >> official ones? >> What is the benefit of one approach over the other? >> >> let's discuss! >> >> LieGrue, >> strub >> >> >
