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 <[email protected]> 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 > >
