2016-09-25 17:54 GMT+02:00 John D. Ament <johndam...@apache.org>: > On Sun, Sep 25, 2016 at 11:49 AM Romain Manni-Bucau <rmannibu...@gmail.com > > > wrote: > > > 2016-09-25 17:40 GMT+02:00 John D. Ament <johndam...@apache.org>: > > > > > On Sun, Sep 25, 2016 at 11:37 AM Romain Manni-Bucau < > > rmannibu...@gmail.com > > > > > > > wrote: > > > > > > > 2016-09-25 17:33 GMT+02:00 Thomas Andraschko < > > > andraschko.tho...@gmail.com > > > > >: > > > > > > > > > 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 > > > > > > > > > > > > > we can switch them of on CDI 2 while we still maintain it on CDI 1.0, > > > that > > > > said not sure we should switch them off, all are not really standard > I > > > > think and impl can still be important (anyway we can work on a list > on > > > > another thread maybe) > > > > > > > > > > IMHO, we do a disservice to the community by keeping both CDI 1.0 and > 2.0 > > > in the same release branch. We can't safely compile against both CDI > 1.0 > > > and 2.0 in the same profile. > > > > > > > > right but was not the proposal which was to keep current branch and add > CDI > > 2.0 features in another module and run this one only on CDI 2 servers but > > still run on CDI 2.0 servers the other modules through jenkins. > > > > I can't even follow what you're trying to say here unfortunately. As I > understand it, my proposal is to make a separate 2.0 branch while 1.0 lives > on in master, probably until we get to a point where 1.x becomes purely > maintenance and 2.x is the mainline for new features. We can probably even > weigh out back porting features based on community need. > > I think what you're trying to propose is that we have a CDI2 module which > serves as an implementation of our core library but built on CDI 2 APIs. > This will work, but would require us to maintain the api JARs signature due > to internal usage, unless you're meaning that we have a CDI2 impl for each > module? > > > I'm proposaing to keep current structure, add a -cdi2 for the feature requiring CDI 2 or not meaning anything for CDI 1 and that's it. No reimplementation until it gets needed.
> > > > > > Clearly the question is cost(2 branches) <?> cost(1 branch). > > > > Suppose you duplicate the code 1s, you will get 2 core-api/core-impl > > modules which would be the same so you would change the groupId or > artifact > > arbitrarly? I find this clearly more misleading than having a ds-cdi2 > > module and keeping the original ones as it is today when it will be time > of > > migrations. > > > > I disagree. We make it clear on our website that DS 2.0 + is all based on > CDI 2. There is no second artifact or group id required. Its simply > semantic versioning. DS 2.0 is not backwards compatible to DS 1.x. > > Ok, not a fan of that cause it prevents software evolution but would work and is probably ok/consistent for DS. > > > > > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > >
