We should keep BeanManagerProvider etc around anyway. We could probably mark them as @deprecated. But that's it. Most EE apps in production are still running on EE6 today. That's the sad truth :(
There is imo also no technical need to get rid of BMP. LieGrue, strub > On Sunday, 25 September 2016, 17:42, John D. Ament <[email protected]> > wrote: > > On Sun, Sep 25, 2016 at 11:40 AM Romain Manni-Bucau > <[email protected]> > wrote: > >> 2016-09-25 17:37 GMT+02:00 John D. Ament <[email protected]>: >> >> > On Sun, Sep 25, 2016 at 11:34 AM Thomas Andraschko < >> > [email protected]> 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. >> > >> > >> we delegate on CDI 1.1 already so it doesn't hurt >> >> >> > 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. >> > >> > >> we can still extract these "core" part in a module on the main > branch >> >> Personally I see it as making DS a bit more modular (even if main >> dependencies are still bringing back the same "stack"). But > typically >> having core-cdi1, config, scope etc... is very seducing, whatever version >> we target, and would also solve the cdi 2 issue, no? >> > > It doesn't solve getting rid of the API, as internally we would need to > still have BeanManagerProvider etc available and executed as static methods. > > > > >> >> >> > John >> > >> > >> > > >> > > 2016-09-25 17:28 GMT+02:00 Romain Manni-Bucau > <[email protected]>: >> > > >> > > > 2016-09-25 17:22 GMT+02:00 John D. Ament > <[email protected]>: >> > > > >> > > > > 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 >> > > > > >> > > > >> > > >> > >> >
