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 13:56:37 GMT
In my defense I'd say neither Jersey nor Resteasy has as many many 
modules as CXF has, lol :-)

On 16/11/17 13:55, Andriy Redko wrote:
> +1 to that, also Jersey has RxJava and RxJava2 modules (at least for
> the client side).
> Thursday, November 16, 2017, 8:51:25 AM, you wrote:
> SB> Hi Andriy
> SB> Yeah, that is true. The only indirect reference to the fact CXF +
> SB> RxJava1 might be combined somehow is that the initial RxJava1 code was
> SB> added after a JIRA request was opened.
> SB> By the way I've browsed around and found out ReastEasy friends have
> SB> RxJava and RxJava2 modules :-).
> SB> I guess the only prob with splitting it into tow modules in CXF is that
> SB> CXF 3.2.1 is known to ship RxJava2 code in the cxf-rt-rs-extension-rx,
> SB> so I guess it would have to be moved to cxf-rt-rs-extension-rx2, and I'd
> SB> not be surprised if it would actually be noticed by CXF 3.2.2 users,
> SB> given that users like trying newer things...
> SB> So perhaps keeping things as is in 3.2.x is the best compromize
> SB> Cheers. Sergey
> SB> On 16/11/17 13:41, Andriy Redko wrote:
>>> 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
>>> 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
>>> 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
>>>>> SB> related code growing, and contributing to a CXF module noise to
>>>>> 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
>>>>> 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
>>>>>>> actively
>>>>>>> supported and maintained (and there are reasons for that, as
>>>>>>> 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
>>>>>>> "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
>>>>>>> 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" <*
<>*> 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 <
>>>>>>> *>>>> <>*>
>>>>>>>>>>> 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
>>>>>>> *

View raw message