Let's do what is really the best for CXF in short term (long term is obviously dropping RxJava 1.x). I saw and still see RxJava 1.x in the field, BUT I haven't seen the CXF + RxJava 1.x in use yet :) So my arguments are purely based on assupmtions, not the real facts :-D
SB> It's obviously not only my decision what to do with this code, you are SB> right it's only my opinion (which will stay non-binding) which is to SB> keep where it is now just in case and drop it once the new master opens. SB> To be honest, it does not matter much to me :-), so if few more PMCs say SB> yes, def has to be a new module - then I'll give my +1 and move on, as I SB> said purely from a tech point of view a dedicated module without SB> optional deps is better. SB> I'm simply hesitating, given how much effort went into dropping some old SB> modules from 3.2.x, to start with another module with precisely 4 files SB> (3 in .client subpackage, 1 in .server) with us (me definitely) unlikely SB> contributing to it at this stage. I'd rather spend the limited amount of SB> time I have now on growing the small (but with the prospect of growth) SB> reactivestreams lib we've discussed with John which can be used by SB> RxJava2 and Reactor code... SB> Cheers, Sergey SB> On 16/11/17 12:02, Andriy Redko wrote: >> Fair enough, if we the new module is not a option (in your opinion), >> I would vote to remove the RxJava 1.x integration and dependency. >> SB> As I said, as far as CXF is concerned, there's no prospect of RxJava >> SB> related code growing, and contributing to a CXF module noise to support >> SB> a legacy library (I know I have to be careful now about the wording:-), >> SB> I'm meaning here RxJava2 embracing org.ractivestreams) is not worth it >> IMHO. >> SB> If you check my earlier reply, I suggested to keep it where it is now >> SB> after all. So if we have some users somewhere deciding to stay with >> SB> RxJava then they'd have the support they need. >> SB> Cheers, SErgey >> SB> On 16/11/17 11:45, Andriy Redko wrote: >>>> Got it, so "legacy" part is questionable here. Check out the releases page, >>>> https://github.com/ReactiveX/RxJava/releases, the 1.x is still being >>>> actively >>>> supported and maintained (and there are reasons for that, as I >>>> mentioned). So >>>> it is really up to us to decide, should we support it or not, but with >>>> the new >>>> module we could get the stats and make the decision not based on >>>> "legacy" but >>>> if it is used or not. I don't have particular attachments to RxJava 1.x so >>>> if you are confident no one is relying on this integration, I would >>>> agree with >>>> you and we should better remove this code. >>>> *SB> The problem is not about a new module, but about RxJava is a legacy >>>> lib, >>>> SB> and having a module with 2/3 files with no prospect of going beyond >>>> this >>>> SB> number is not worth it IMHO >>>> SB> Sergey >>>> SB> On 16/11/17 11:15, Andrey Redko wrote: >>>>>> Hey Sergey, >>>>>> I think the "ideal" in this case depends on whom to ask. For us - yet >>>>>> another module to support, for users - out of the box integration. With >>>>>> new >>>>>> module we could collect a bit more insights if people use it or not. No >>>>>> use >>>>>> - drop in next releases. Thanks. >>>>>> Best Regards, >>>>>> Andriy Redko >>>>>> On Nov 16, 2017 4:42 AM, "Sergey Beryozkin" <*sberyoz...@gmail.com >>>>>> <mailto:sberyoz...@gmail.com>*> wrote: >>>>>>> Hi Andriy >>>>>>> As I said, introducing a dedicated support for a legacy library in the >>>>>>> form of a new module would not be ideal IMHO >>>>>>> Cheers, Sergey >>>>>>> On 15/11/17 23:53, Andriy Redko wrote: >>>>>>>> Hey Sergey, >>>>>>>> That would be ideal I think (move RxJava into separate module). RxJava2 >>>>>>>> and >>>>>>>> RxJava are quite different frameworks, some people just stuck with >>>>>>>> RxJava >>>>>>>> so >>>>>>>> we could support them there. Thanks. >>>>>>>> Best Regards, >>>>>>>> Andriy Redko >>>>>>>> JDA> What about just leaving the old RxJava code in a module by itself >>>>>>>> (when I >>>>>>>> JDA> was looking recently, it didn't make much sense to see both RxJava >>>>>>>> and >>>>>>>> JDA> RxJava2 in one module). >>>>>>>> JDA> On Wed, Nov 15, 2017 at 10:56 AM Sergey Beryozkin < >>>> *>>>> sberyoz...@gmail.com <mailto:sberyoz...@gmail.com>*> >>>>>>>> JDA> wrote: >>>>>>>> Hi >>>>>>>> cxf-rt-rs-extension-rx ships the code for both (old) RxJava and RxJava2 >>>>>>>>>> code. It supports returning RxJava2 Flowable and Observable on the >>>>>>>>>> server and accepting it on the client, and the same for the (old) >>>>>>>>>> RxJava >>>>>>>>>> Observable... >>>>>>>> While even the (old) RxJava code is very new for CXF, the reality is >>>>>>>>>> that RxJava has been around for a while now and with RxJava2 >>>>>>>>>> embracing >>>>>>>>>> org.reactivestreams, it's hard to see CXF users preferring to start >>>>>>>>>> with >>>>>>>>>> the (old) RxJava. >>>>>>>> The other minor problem is that cxf-rt-rs-extension-rx has optional >>>>>>>>>> RxJava and RxJava2 deps to be able to ship the relevant code in the >>>>>>>>>> same >>>>>>>>>> module and splitting it into 2 modules will be too much at this >>>>>>>>>> point. >>>>>>>> I suggest that unless some users confirm (I CC to the users) that they >>>>>>>>>> need to use the (old) RxJava code, then we just remove it and make >>>>>>>>>> things much simpler... >>>>>>>> Thanks, Sergey >>>> *
