would imo introduce too many layers which might be hard to maintain in the long run. With the current plugin structure you can already run without even class scanning and dynamic bytecode tinkering if one wants. So don't think it's worth to add another layer of abstraction in the middle.
LieGrue, strub > Am 02.06.2022 um 21:32 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>: > > 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 > <mailto: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 >> <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
