> Basically, one sticking target I see continually is BeanManagerProvider. We already use CDI.current() internally if it is available (via reflection). So no need to upgrade it just for this feature.
> but its because we didn't make a DS version > that was CDI 1.1+ compatible. Nope, ALL our versions since day one are CDI-1.1+ compatible. And we also already make use of a few important features. But only via reflection. > features like manual injection of fields, which > could be replaced by Unmaanaged. I don't like Unmanaged as it can easily create mem leaks. It is imo as unnecessary as @New used to be... I already expressed my concerns in the EG, but it's too late to get rid of it now. Also note that Unmanaged always creates a newInstance while the DeltaSpike utility method injects into a given EXISTING instance. That is a *huge* difference. LieGrue, strub > On Sunday, 25 September 2016, 17:37, John D. Ament <johndam...@apache.org> > wrote: > > On Sun, Sep 25, 2016 at 11:34 AM Thomas Andraschko < > andraschko.tho...@gmail.com> wrote: > >> not sure if a cdi2-module is enough >> we should also get rid of some of our api's which are in CDI 2.0 now >> > > Yes. I agree. Basically, one sticking target I see continually is > BeanManagerProvider. Maybe we keep it around as a utility and for > backwards compatibility, but its now available as CDI.current(), to do > programmatic look up. > > In addition, there are features like manual injection of fields, which > could be replaced by Unmaanaged. I know as a user of CDI 1.2, seeing both > available makes me confused, but its because we didn't make a DS version > that was CDI 1.1+ compatible. > > John > > > >> >> 2016-09-25 17:28 GMT+02:00 Romain Manni-Bucau > <rmannibu...@gmail.com>: >> >> > 2016-09-25 17:22 GMT+02:00 John D. Ament > <johndam...@apache.org>: >> > >> > > Hey guys, >> > > >> > > Since its inception, DeltaSpike has targeted Java EE 6 and lower, > and >> as >> > a >> > > result the CDI 1.0 runtime. We have maintained a pretty > backwards >> > > compatible code base for 5 years now. >> > > >> > > CDI 2.0 is going to wrap up in January, if current schedules > align >> > > correctly. >> > > >> > > I'd like to propose that we start a branch for 2.0 > development now. It >> > > would be a good place to put fixes for >> > > https://issues.apache.org/jira/browse/DELTASPIKE-1206 and other >> > > enhancements that we can make to our core runtime to better > integrate >> > with >> > > CDI 1.1/1.2/2.0 features that have been added. In addition to > the >> Java 8 >> > > upgrade taking place there. >> > > >> > > We can keep master on 1.x for patches that may be needed for the > 1.x >> > line, >> > > and rebase them with a 2.0 branch to make sure both branches get > the >> > fixes. >> > > >> > > WDYT? >> > > >> > >> > What feature do we target and need CDI 2.0 for it? If none I think we >> don't >> > need the branch yet, if enough we should also think to have a cdi2 > module >> > to avoid to fork code while 1.0/1.1 is maintained >> > >> > >> > > >> > > John >> > > >> > >> >
