Le jeu. 2 juin 2022 à 22:44, Mark Struberg <strub...@yahoo.de.invalid> a écrit :
> 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. > Thing is that currently you dont get most benefit, just tech extension points to make the run work: - you leverage jakarta/javax and their mess+breaking changes+inconsistencies from v4 - you get more than needed in api - you have constraints on beans you dont need Your proposal is just the same but half baked since we are compatible or we are not, this is why I think we should propose something really stable or maybe just stick to impl the spec (modularly or not is a detail but tck require both parts of the spec so passing only one is pointless for users IMHO). > 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 > >
