Hi, Some times ago I proposed to extract a cdi-like-light owb bundle which would be a minimal IoC without the cdi 2.0 boilerplate and probably unsafe free to be "all env friendly". This is very close to owb-se except a few spi, defaults and jakarta dep.
Making it cdi-se/ee as an impl sounds more valuable today for the project IMHO - because we tend to go lightweight cause of the cloud move and projects stacking too much are not that adopted - and is still compatible with your idea so can be worth starting owb 3 from these basis with a light owb IoC api/spi (TBD if we inherit from jakarta or not) and then back owb-impl by this "owb-core" and finally impl your idea on this new api? Le jeu. 2 juin 2022 à 21:04, Mark Struberg <strub...@yahoo.de.invalid> a écrit : > hi folks! > > I had an idea about how we could implement CDI-4.0 without all the > overhead it brings. > The goal is to keep OWB as light as possible but as compatible as possible. > > The idea is to use the standard eclipse jcdi package and split it in 2 > parts via maven-shade plugin or simple unzip/zip repackaging. > This is necessary as JBoss refused to do it properly inside the spec > itself but forced the full 'light' (which is actually adding 30% more code > to the CDI api) on all users, regardless whether they need it or not. > > Here you can find more information about the background of the split and > how it's done: > https://github.com/jakartaee/cdi/pull/582 < > https://github.com/jakartaee/cdi/pull/582> > > I'd like to do the same, but for now just implement the clasic Jakarta EE > part without the 'CDI lite' overhead. > If we later find some time we can still implement CDI-lite as either an > OWB plugin or even as a standard portable extension. This can be done here > or as part of TomEE for example. > > I think we might be rather quick to get things going that way. > > Wdyt about that idea? > > LieGrue, > strub
