cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: Remove obsolete RxJava code and keep RxJava2 only one
Date Thu, 16 Nov 2017 12:24:40 GMT
It's obviously not only my decision what to do with this code, you are 
right it's only my opinion (which will stay non-binding) which is to 
keep where it is now just in case and drop it once the new master opens.

To be honest, it does not matter much to me :-), so if few more PMCs say 
yes, def has to be a new module - then I'll give my +1 and move on, as I 
said purely from a tech point of view a dedicated module without 
optional deps is better.

I'm simply hesitating, given how much effort went into dropping some old 
modules from 3.2.x, to start with another module with precisely 4 files 
(3 in .client subpackage, 1 in .server) with us (me definitely) unlikely 
contributing to it at this stage. I'd rather spend the limited amount of 
time I have now on growing the small (but with the prospect of growth) 
reactivestreams lib we've discussed with John which can be used by 
RxJava2 and Reactor code...

Cheers, Sergey
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,
>>>, 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
>>>>> 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" <*
<>*> wrote:
>>>>>> Hi Andriy
>>>>>> As I said, introducing a dedicated support for a legacy library in
>>>>>> 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).
>>>>>>> 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 <
>>> *>>>> <>*>
>>>>>>> JDA> wrote:
>>>>>>> Hi
>>>>>>> cxf-rt-rs-extension-rx ships the code for both (old) RxJava and
>>>>>>>>> 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
>>>>>>>>> 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
>>> *

View raw message