On Sun, Sep 25, 2016 at 11:44 AM Romain Manni-Bucau <[email protected]> wrote:
> 2016-09-25 17:42 GMT+02:00 John D. Ament <[email protected]>: > > > 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. > > > > > Well it does since handling that is far easier than handling 2 distinct > projects and a merge policy. > Hence why I was saying two different branches. It leaves users less confused. It allows us to split up modules and make sure people know about migration paths, etc, and the use of a major version # makes it clearer that there's a big change coming. > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > >
