You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Sergey Beryozkin <sb...@gmail.com> on 2017/11/15 15:56:29 UTC
Remove obsolete RxJava code and keep RxJava2 only one
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
Re: Remove obsolete RxJava code and keep RxJava2 only one
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi,
Indeed, creating a new module specifically for RxJava is technically
clean, but creating it for a code which no one will probably use and
also adding one module to the large number of CXF modules, with only 2/3
Java files :-) is a bit problematic...
I guess I can keep it as is in 3.2.x but remove it once a new master
opens...
Thanks, Sergey
On 15/11/17 16:04, John D. Ament wrote:
> What about just leaving the old RxJava code in a module by itself (when I
> was looking recently, it didn't make much sense to see both RxJava and
> RxJava2 in one module).
>
> On Wed, Nov 15, 2017 at 10:56 AM Sergey Beryozkin <sb...@gmail.com>
> 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
>>
>
Re: Remove obsolete RxJava code and keep RxJava2 only one
Posted by Sergey Beryozkin <sb...@gmail.com>.
I'd still favour removing RxJava, if you would like to keep it then I
guess the new module would indeed have to be introduced
Cheers, Sergey
On 06/02/18 03:49, John D. Ament wrote:
> I was just about to remove the optional marking on reactive streams, and
> noticed that rxjava was still around. I guess it was decided to keep it?
> I'll point out, this now makes the dependency chain even harder to follow
> (since rxjava2 uses reactive streams, but rxjava does not).
>
> John
>
> On Wed, Nov 15, 2017 at 6:53 PM Andriy Redko <dr...@gmail.com> 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 <
>> sberyozkin@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
>>
>>
>>
>
Re: Remove obsolete RxJava code and keep RxJava2 only one
Posted by Sergey Beryozkin <sb...@gmail.com>.
I'd still favour removing RxJava, if you would like to keep it then I
guess the new module would indeed have to be introduced
Cheers, Sergey
On 06/02/18 03:49, John D. Ament wrote:
> I was just about to remove the optional marking on reactive streams, and
> noticed that rxjava was still around. I guess it was decided to keep it?
> I'll point out, this now makes the dependency chain even harder to follow
> (since rxjava2 uses reactive streams, but rxjava does not).
>
> John
>
> On Wed, Nov 15, 2017 at 6:53 PM Andriy Redko <dr...@gmail.com> 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 <
>> sberyozkin@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
>>
>>
>>
>
Re: Remove obsolete RxJava code and keep RxJava2 only one
Posted by "John D. Ament" <jo...@apache.org>.
I was just about to remove the optional marking on reactive streams, and
noticed that rxjava was still around. I guess it was decided to keep it?
I'll point out, this now makes the dependency chain even harder to follow
(since rxjava2 uses reactive streams, but rxjava does not).
John
On Wed, Nov 15, 2017 at 6:53 PM Andriy Redko <dr...@gmail.com> 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 <
> sberyozkin@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
>
>
>
Re: Remove obsolete RxJava code and keep RxJava2 only one
Posted by Sergey Beryozkin <sb...@gmail.com>.
In my defense I'd say neither Jersey nor Resteasy has as many many
modules as CXF has, lol :-)
Sergey
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 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" <*sberyozkin@gmail.com <ma...@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 <
>>>>>>> *>>>> sberyozkin@gmail.com <ma...@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
>
>
>
>
>
>
>>>>>>> *
>
>
>
Re: Remove obsolete RxJava code and keep RxJava2 only one
Posted by Andriy Redko <dr...@gmail.com>.
+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 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" <*sberyozkin@gmail.com <ma...@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 <
>>>>>> *>>>> sberyozkin@gmail.com <ma...@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
>>>>>> *
Re: Remove obsolete RxJava code and keep RxJava2 only one
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Andriy
Yeah, that is true. The only indirect reference to the fact CXF +
RxJava1 might be combined somehow is that the initial RxJava1 code was
added after a JIRA request was opened.
By the way I've browsed around and found out ReastEasy friends have
RxJava and RxJava2 modules :-).
I guess the only prob with splitting it into tow modules in CXF is that
CXF 3.2.1 is known to ship RxJava2 code in the cxf-rt-rs-extension-rx,
so I guess it would have to be moved to cxf-rt-rs-extension-rx2, and I'd
not be surprised if it would actually be noticed by CXF 3.2.2 users,
given that users like trying newer things...
So perhaps keeping things as is in 3.2.x is the best compromize
Cheers. Sergey
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 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" <*sberyozkin@gmail.com <ma...@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 <
>>>>> *>>>> sberyozkin@gmail.com <ma...@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
>
>
>
>
>
>
>>>>> *
>
>
Re: Remove obsolete RxJava code and keep RxJava2 only one
Posted by Andriy Redko <dr...@gmail.com>.
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" <*sberyozkin@gmail.com <ma...@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 <
>>>> *>>>> sberyozkin@gmail.com <ma...@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
>>>> *
Re: Remove obsolete RxJava code and keep RxJava2 only one
Posted by Sergey Beryozkin <sb...@gmail.com>.
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,
>>> 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" <*sberyozkin@gmail.com <ma...@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 <
>>> *>>>> sberyozkin@gmail.com <ma...@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
>>>
>>>
>>>
>>>
>>>
>>>
>>> *
>
Re: Remove obsolete RxJava code and keep RxJava2 only one
Posted by Andriy Redko <dr...@gmail.com>.
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" <*sberyozkin@gmail.com <ma...@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 <
>> *>>>> sberyozkin@gmail.com <ma...@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
>>
>>
>>
>>
>>
>>
>> *
Re: Remove obsolete RxJava code and keep RxJava2 only one
Posted by Sergey Beryozkin <sb...@gmail.com>.
As I said, as far as CXF is concerned, there's no prospect of RxJava
related code growing, and contributing to a CXF module noise to support
a legacy library (I know I have to be careful now about the wording:-),
I'm meaning here RxJava2 embracing org.ractivestreams) is not worth it IMHO.
If you check my earlier reply, I suggested to keep it where it is now
after all. So if we have some users somewhere deciding to stay with
RxJava then they'd have the support they need.
Cheers, SErgey
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" <*sberyozkin@gmail.com <ma...@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 <
> *>>>> sberyozkin@gmail.com <ma...@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
>
>
>
>
>
>
> *
Re: Remove obsolete RxJava code and keep RxJava2 only one
Posted by Sergey Beryozkin <sb...@gmail.com>.
The problem is not about a new module, but about RxJava is a legacy lib,
and having a module with 2/3 files with no prospect of going beyond this
number is not worth it IMHO
Sergey
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" <sb...@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 <
>>> sberyozkin@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
>>>>>
>>>>
>>>
>>>
>
Re: Remove obsolete RxJava code and keep RxJava2 only one
Posted by Andrey Redko <dr...@gmail.com>.
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" <sb...@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 <
>> sberyozkin@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
>>>>
>>>
>>
>>
Re: Remove obsolete RxJava code and keep RxJava2 only one
Posted by Sergey Beryozkin <sb...@gmail.com>.
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 <sb...@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
>
>
Re: Remove obsolete RxJava code and keep RxJava2 only one
Posted by "John D. Ament" <jo...@apache.org>.
I was just about to remove the optional marking on reactive streams, and
noticed that rxjava was still around. I guess it was decided to keep it?
I'll point out, this now makes the dependency chain even harder to follow
(since rxjava2 uses reactive streams, but rxjava does not).
John
On Wed, Nov 15, 2017 at 6:53 PM Andriy Redko <dr...@gmail.com> 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 <
> sberyozkin@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
>
>
>
Re: Remove obsolete RxJava code and keep RxJava2 only one
Posted by Andriy Redko <dr...@gmail.com>.
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 <sb...@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
Re: Remove obsolete RxJava code and keep RxJava2 only one
Posted by Andriy Redko <dr...@gmail.com>.
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 <sb...@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
Re: Remove obsolete RxJava code and keep RxJava2 only one
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi,
Indeed, creating a new module specifically for RxJava is technically
clean, but creating it for a code which no one will probably use and
also adding one module to the large number of CXF modules, with only 2/3
Java files :-) is a bit problematic...
I guess I can keep it as is in 3.2.x but remove it once a new master
opens...
Thanks, Sergey
On 15/11/17 16:04, John D. Ament wrote:
> What about just leaving the old RxJava code in a module by itself (when I
> was looking recently, it didn't make much sense to see both RxJava and
> RxJava2 in one module).
>
> On Wed, Nov 15, 2017 at 10:56 AM Sergey Beryozkin <sb...@gmail.com>
> 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
>>
>
Re: Remove obsolete RxJava code and keep RxJava2 only one
Posted by "John D. Ament" <jo...@apache.org>.
What about just leaving the old RxJava code in a module by itself (when I
was looking recently, it didn't make much sense to see both RxJava and
RxJava2 in one module).
On Wed, Nov 15, 2017 at 10:56 AM Sergey Beryozkin <sb...@gmail.com>
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
>
Re: Remove obsolete RxJava code and keep RxJava2 only one
Posted by Maxim Solodovnik <so...@gmail.com>.
Well known issue :))
It is easy to add something to open source project
and really hard to remove :))))
you can start a VOTE :))))
On Wed, Nov 15, 2017 at 11:53 PM, Sergey Beryozkin <sb...@gmail.com>
wrote:
> Hi Christian
>
> Thanks, I'd rather just remove it, but given that RxJava was introduced on
> the user request, I guess we may as well keep it for a bit after all.
> Once the code makes it into CXF it then becomes tricky to remove it :-)
>
> Sergey
> On 15/11/17 16:09, Christian Schneider wrote:
>
>> +1
>> for removing the old rxjava support
>>
>> I would also be fine with it living in a separate module.
>>
>> Christian
>>
>> 2017-11-15 16:56 GMT+01:00 Sergey Beryozkin <sb...@gmail.com>:
>>
>> 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
>>>
>>>
>>
>>
>>
--
WBR
Maxim aka solomax
Re: Remove obsolete RxJava code and keep RxJava2 only one
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Christian
Thanks, I'd rather just remove it, but given that RxJava was introduced
on the user request, I guess we may as well keep it for a bit after all.
Once the code makes it into CXF it then becomes tricky to remove it :-)
Sergey
On 15/11/17 16:09, Christian Schneider wrote:
> +1
> for removing the old rxjava support
>
> I would also be fine with it living in a separate module.
>
> Christian
>
> 2017-11-15 16:56 GMT+01:00 Sergey Beryozkin <sb...@gmail.com>:
>
>> 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
>>
>
>
>
Re: Remove obsolete RxJava code and keep RxJava2 only one
Posted by Christian Schneider <ch...@die-schneider.net>.
+1
for removing the old rxjava support
I would also be fine with it living in a separate module.
Christian
2017-11-15 16:56 GMT+01:00 Sergey Beryozkin <sb...@gmail.com>:
> 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
>
--
--
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
Computer Scientist
http://www.adobe.com
Re: Remove obsolete RxJava code and keep RxJava2 only one
Posted by "John D. Ament" <jo...@apache.org>.
What about just leaving the old RxJava code in a module by itself (when I
was looking recently, it didn't make much sense to see both RxJava and
RxJava2 in one module).
On Wed, Nov 15, 2017 at 10:56 AM Sergey Beryozkin <sb...@gmail.com>
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
>