Re: New Java 9 master

[Christian Schneider]

2017-11-17 4:40 GMT+01:00 Jeff Genender :

>
>
> > On Nov 16, 2017, at 6:02 AM, Christian Schneider <
> ch...@die-schneider.net> wrote:
> >
> > I am not sure sure about the need for Java 9 modules. Currently I see no
> > user requesting this.
>
> We need a user to request it?  Whats wrong with us looking in a crystal
> ball?  Doesn’t one of our own committers count as a user requesting it?
>

Absolutely Sergeys request is surely valid. I just fear the additional
overhead and that a java 9 master might prevent some java 8 developers from
supplying patches as they would be forced to develop on java 9.
So I completely agree that we will have a java 9 master at some point ..
The question is only when. My approach to this is to switch as late as
possible while still allowing us to explore java 9.

>
> > It is also not yet fully clear how these modules
> > behave in OSGi.
>
> They are just jars with manifests, no?  I would believe they would both
> operate based on their own manifest file contents.  Let stay it and find
> out. ;-). No harm no foul.
>

Yes. I completely agree to try this. I would rather experiment with this in
a side branch though. The ideal solution would be a jar that is both a java
9 module and a regular java 8 jar. Not sure if that works though.
If Dans assumption is right that all our deps must be JAva 9 modules before
we switch this will take quite a while anyway. So I think the right time to
switch to add java 9 modules is when all dependencies are modules.
For other java 9 features we might want to provide support earlier though.

>
> >
> > So I think the current situation with a master that works on Java 9 and
> > Java 8 is a pretty good situation that we should keep for as long as
> > possible.
> > I am not sure how attractive the other Java 9 features are. Personally I
> > were really eager to adopt Java 8 because of the closures but I see no
> real
> > need for myself to rush to java 9.
> >
>
> But others do use it.  I'm one of those who did go all in JDK 9… call me a
> cutting edge person. ;-). I have people asking me all the time about this.
> Different strokes for different folks. ;-)
>
> > When I remember how reluctant we were when it came to adopting the
> previous
> > java versions like 7 and 8 as minimal requirement I think it makes sense
> to
> > do this rather slowly.
>
> And what did that reluctancy buy us except people wondering what is taking
> so long.  Why not get ahead of the curve this time instead of being
> dinosaurs and the last ones to the table.
>
> Whats the harm in doing it?  Its just a git repo that has zero impact on
> the Java 8 code base.  Everything will feed it as an upstream code base.
>

The harm is that every change in CXF will be coded and tested on the Java 9
master first then. Additionally it would need to be backported to the older
branches. So we would force all CXF developers to switch to Java 9.
This is the price and it will be especially high while most people are
still on Java 8.

On the other hand the gain is that Java 9 developers can already work with
Java 9 features. At the start this gain is very low. It will grow over time
when people migrate to Java 9.

So the question is simply when there is the right time for this switch.

Christian


-- 
-- 
Christian Schneider
http://www.liquid-reality.de


Computer Scientist
http://www.adobe.com

Re: New Java 9 master

[Jeff Genender]

> On Nov 16, 2017, at 7:02 AM, Sergey Beryozkin  wrote:
> 
> Indeed it will take a long time for a team with the limited resources to have 
> CXF embracing Java 9. Postponing the start of this long process for 2 years 
> or so and wait for the users to come in and say, when will CXF will do what 
> SpringBoot with Java 9 can do, is not strategically right move IMHO.


+1000

> 
> Have the Java 9 branch, let people spend as much time as needed to play 
> there, keep going with Java 8+9 in 3.2.1. I don't see where the conflict is

+1,000,000!!!

Jeff

> 
> Cheers. Sergey
> On 16/11/17 13:53, Andriy Redko wrote:
>> Modules are really far away in the future (IMHO). As per my understanding, we
>> could think about real modules only when all our dependencies are 
>> modularized,
>> which would take quite a lot of time I suppose. The Reactive Streams part is
>> really appealing *BUT* even there we **could** keep the same master for 8 
>> and 9
>> (http://openjdk.java.net/jeps/238).
>> Honestly, I am not 100% sure we have to branch off the new master and keep it
>> Java 9 only right now. May be the good moment will be when we discountinue
>> 3.1.x so at least the code will be much easier to cherry-pick?
>> Best Regards,
>>Andriy Redko
>> CS> I am not sure sure about the need for Java 9 modules. Currently I see no
>> CS> user requesting this. It is also not yet fully clear how these modules
>> CS> behave in OSGi. As far as I understood as soon as we start with this we
>> CS> have code that is not working in Java 8. As we require every change to be
>> CS> done in master first this means we have a lot of back port work. A Java 9
>> CS> only master will also make it much harder for Java 8 users to supply pull
>> CS> requests as they have to develop and test on java 9 which is not their
>> CS> production system.
>> CS> So I think the current situation with a master that works on Java 9 and
>> CS> Java 8 is a pretty good situation that we should keep for as long as
>> CS> possible.
>> CS> I am not sure how attractive the other Java 9 features are. Personally I
>> CS> were really eager to adopt Java 8 because of the closures but I see no 
>> real
>> CS> need for myself to rush to java 9.
>> CS> When I remember how reluctant we were when it came to adopting the 
>> previous
>> CS> java versions like 7 and 8 as minimal requirement I think it makes sense 
>> to
>> CS> do this rather slowly.
>> CS> Christian
>> CS> 2017-11-16 13:31 GMT+01:00 Sergey Beryozkin :
 Hi Andriy
 I'm only presuming that yes, a Java 9 only master would have to support
 the new Java 9 modules system, so I'd say a lot of exciting work would
 await for the CXF dev community :-)
 Cheers, Sergey
 On 16/11/17 12:19, Andriy Redko wrote:
> Hey Sergey,
> Do we have a goal to support Java 9 modules (aka Jigsaw) for
> the new master branch? Or we just looking to benefit from the
> latest changes in stardand library (as you mentioned, Flow & Co,
> collections are also a good example)? Is our current master JDK9
> compatible actually (haven't seen successfull builds from
> https://builds.apache.org/job/CXF-Master-JDK9) ?
> Best Regards,
>  Andriy Redko
> SB> It's pretty simple really. It's about having a new impetus for the CXF
> SB> development.
> SB> Without a Java 9 only master CXF will be about fixing the bugs only.
> SB> JAX-WS is done long time ago, next version of JAX-RS will take N
> amount
> SB> of time to materialize.
> SB> Java 9 with its Flow class will let CXF do new work around Reactive
> SB> support. It will have new features that only work with Java 9 and may
> SB> give new ideas for the contributions.
> SB> 3.2.x is at the start of its life-cycle and will have a couple of
> years
> SB> at least for it to retire, giving Java 8 support.
> SB> 3.1.x has probably 6 months or so left in it, and after it's gone we
> SB> will have 3.2.x and 4.0.x or whatever new version is preferred.
> SB> Sergey
> SB> On 16/11/17 08:15, Dennis Kieselhorst wrote:
>> On 2017-11-16 07:27, Christian Schneider 
>>> wrote:
 I dont think we can already predict when users move to Java 9.
 So creating a Java 9 only branch at this time means we have to
 maintain two
 main branches over a long time.
 What is the rationale behind a Java 9 only branch compared to being
 Java 9
 and Java 8 compatible on master?
>>> I also don't see a good reason to do that at the moment. Let's release
>>> the XJC plugin and users should be able to use CXF with Java 9 or am I
>>> missing something?
>>> Cheers
>>> Dennis
>> CS> --

Re: New Java 9 master

[Jeff Genender]

> On Nov 16, 2017, at 6:02 AM, Christian Schneider  
> wrote:
> 
> I am not sure sure about the need for Java 9 modules. Currently I see no
> user requesting this.

We need a user to request it?  Whats wrong with us looking in a crystal ball?  
Doesn’t one of our own committers count as a user requesting it?

> It is also not yet fully clear how these modules
> behave in OSGi.

They are just jars with manifests, no?  I would believe they would both operate 
based on their own manifest file contents.  Let stay it and find out. ;-). No 
harm no foul.

> As far as I understood as soon as we start with this we
> have code that is not working in Java 8. As we require every change to be
> done in master first this means we have a lot of back port work. A Java 9
> only master will also make it much harder for Java 8 users to supply pull
> requests as they have to develop and test on java 9 which is not their
> production system.

How is this any different than what we have done in the past with our multiple 
versions? CXF for JDK9 with modules… perhaps a CXF 4?
> 
> So I think the current situation with a master that works on Java 9 and
> Java 8 is a pretty good situation that we should keep for as long as
> possible.
> I am not sure how attractive the other Java 9 features are. Personally I
> were really eager to adopt Java 8 because of the closures but I see no real
> need for myself to rush to java 9.
> 

But others do use it.  I'm one of those who did go all in JDK 9… call me a 
cutting edge person. ;-). I have people asking me all the time about this.  
Different strokes for different folks. ;-)

> When I remember how reluctant we were when it came to adopting the previous
> java versions like 7 and 8 as minimal requirement I think it makes sense to
> do this rather slowly.

And what did that reluctancy buy us except people wondering what is taking so 
long.  Why not get ahead of the curve this time instead of being dinosaurs and 
the last ones to the table.

Whats the harm in doing it?  Its just a git repo that has zero impact on the 
Java 8 code base.  Everything will feed it as an upstream code base.

I’m not getting why the pushback..

Jeff


> 
> Christian
> 
> 2017-11-16 13:31 GMT+01:00 Sergey Beryozkin :
> 
>> Hi Andriy
>> 
>> I'm only presuming that yes, a Java 9 only master would have to support
>> the new Java 9 modules system, so I'd say a lot of exciting work would
>> await for the CXF dev community :-)
>> 
>> Cheers, Sergey
>> 
>> On 16/11/17 12:19, Andriy Redko wrote:
>> 
>>> Hey Sergey,
>>> 
>>> Do we have a goal to support Java 9 modules (aka Jigsaw) for
>>> the new master branch? Or we just looking to benefit from the
>>> latest changes in stardand library (as you mentioned, Flow & Co,
>>> collections are also a good example)? Is our current master JDK9
>>> compatible actually (haven't seen successfull builds from
>>> https://builds.apache.org/job/CXF-Master-JDK9) ?
>>> 
>>> Best Regards,
>>> Andriy Redko
>>> 
>>> SB> It's pretty simple really. It's about having a new impetus for the CXF
>>> SB> development.
>>> 
>>> SB> Without a Java 9 only master CXF will be about fixing the bugs only.
>>> SB> JAX-WS is done long time ago, next version of JAX-RS will take N
>>> amount
>>> SB> of time to materialize.
>>> 
>>> SB> Java 9 with its Flow class will let CXF do new work around Reactive
>>> SB> support. It will have new features that only work with Java 9 and may
>>> SB> give new ideas for the contributions.
>>> 
>>> SB> 3.2.x is at the start of its life-cycle and will have a couple of
>>> years
>>> SB> at least for it to retire, giving Java 8 support.
>>> 
>>> SB> 3.1.x has probably 6 months or so left in it, and after it's gone we
>>> SB> will have 3.2.x and 4.0.x or whatever new version is preferred.
>>> 
>>> SB> Sergey
>>> SB> On 16/11/17 08:15, Dennis Kieselhorst wrote:
>>> 
 On 2017-11-16 07:27, Christian Schneider 
> wrote:
> 
>> I dont think we can already predict when users move to Java 9.
>> So creating a Java 9 only branch at this time means we have to
>> maintain two
>> main branches over a long time.
>> 
>> What is the rationale behind a Java 9 only branch compared to being
>> Java 9
>> and Java 8 compatible on master?
>> 
> 
> I also don't see a good reason to do that at the moment. Let's release
> the XJC plugin and users should be able to use CXF with Java 9 or am I
> missing something?
> 
> Cheers
> Dennis
> 
> 
>>> 
> 
> 
> -- 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> 
> Computer Scientist
> http://www.adobe.com

[GitHub] gonzalad opened a new pull request #26: IDP maxParameter size is set only if positive

[GitBox]

gonzalad opened a new pull request #26: IDP maxParameter size is set only if 
positive
URL: https://github.com/apache/cxf-fediz/pull/26
 
 
   maxParameter size should be set only if positive,
   otherwise, we'll use default value.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: New Java 9 master

[Andriy Redko]

Would it be fair to conclude that for the next couple of months it would
make sense to keep master in "8+9" state, while gradually explore the
real need to introduce the new master (Java 9 only)? I would be curious
to see how RxJava2 and/or Reactor would provide the integration with Java 9
Flow API (https://github.com/ReactiveX/RxJava/wiki/Reactive-Streams) ...

   "The plan is to also support Java 9 j.u.c.Flow types by leveraging new Java
   multi-versioned jars to support this when using RxJava 2.x in Java 9 while
   still working on Java 8."

I have heard that multi-versioned jars are **not** straigthfoward, but perhaps
better than keeping two masters.

DK> I’d much rather keep master a “8+9” type of thing for a while.I don’t 
see ANYONE moving to Java 9 for production stuff any time soon.

DK> That said, at some point soon, I’d like to make master more “Java 9 
Friendly” and hopefully release a 3.3 at some
DK> point in the future that supports java8, but may be more friendly for 
Java9.Not 100% sure what that would
DK> entail, but I would definitely be open to the idea of releases being done 
with Java9 that would allow additional modules for Java9 users.

DK> It’s kind of similar to how we moved from JAX-WS 2.1 to 2.2.Until we 
went Java7 only, we had a separate profile
DK> that added additional src directories and such for JAX-WS 2.2.   On Java 
5/6, we had to do JAX-WS 2.1 so the code in
DK> the normal src/main/java directories was all Java5/6 with JAX-WS 2.1.   
However, we had a separate src/man/jaxws22
DK> source directory that contained the additional classes and such that were 
needed for JAX-WS 2.2.   At release time,
DK> we had to make sure we used the appropriate JDK/Profile to get that 
included.   

DK> Now, what does “Java 9 Friendly” entail?   Not really sure.  Off the top of 
my head, I would definitely start by
DK> including dependencies for all the javax.* API’s.   Example, core depends 
on JAXB so add the jaxb-api jar.This
DK> would definitely reduce the amount of “patch-module” things that are needed 
to use CXF on Java9.   However, it’s not
DK> something to do on 3.2.x as it adds a ton of dependencies that users may 
need/want to exclude so not a “patch”
DK> thing.As part of this, we’d also update to as many dependencies that 
are module friendly as possible.  We
DK> could also have additional source dirs or similar to the tree for Java 9 
“cool things”, providing we can still
DK> compile with —target=1.8.Another example could possibly be an update to 
the http client transport to use the
DK> Java9 HttpClient.   If run on Java8, we’d stick with URLConnection, on 
Java9, use HttpClient. 

DK> I know Java9 supports the “Multi-Release JAR”, but I’m not sure if Maven 
can handle/generate those yet.   Something else to look into.

DK> Dan




>> On Nov 15, 2017, at 6:47 AM, Sergey Beryozkin  wrote:
>> 
>> Hi
>> 
>> Should we open a new Java 9 only master soon enough ?
>> 
>> Thanks, Sergey

Re: New Java 9 master

[Jeff Genender]

Well I don’t necessarily agree about anyone moving to Java 9 anytime soon.  I’m 
beginning to see companies do it, albeit small companies/start ups… but they 
are moving.

I think the necessity for moving to JDK 9 is the modules.  We should think 
about making the jars not only OSGi compliant, but able to work with Jigsaw.  I 
think more and more people will be moving to that since it has become a part of 
the JVM.

Just my ,02.

Jeff


> On Nov 16, 2017, at 9:58 AM, Daniel Kulp  wrote:
> 
> 
> I’d much rather keep master a “8+9” type of thing for a while.I don’t see 
> ANYONE moving to Java 9 for production stuff any time soon.
> 
> That said, at some point soon, I’d like to make master more “Java 9 Friendly” 
> and hopefully release a 3.3 at some point in the future that supports java8, 
> but may be more friendly for Java9.Not 100% sure what that would entail, 
> but I would definitely be open to the idea of releases being done with Java9 
> that would allow additional modules for Java9 users.
> 
> It’s kind of similar to how we moved from JAX-WS 2.1 to 2.2.Until we went 
> Java7 only, we had a separate profile that added additional src directories 
> and such for JAX-WS 2.2.   On Java 5/6, we had to do JAX-WS 2.1 so the code 
> in the normal src/main/java directories was all Java5/6 with JAX-WS 2.1.   
> However, we had a separate src/man/jaxws22 source directory that contained 
> the additional classes and such that were needed for JAX-WS 2.2.   At release 
> time, we had to make sure we used the appropriate JDK/Profile to get that 
> included.   
> 
> Now, what does “Java 9 Friendly” entail?   Not really sure.  Off the top of 
> my head, I would definitely start by including dependencies for all the 
> javax.* API’s.   Example, core depends on JAXB so add the jaxb-api jar.
> This would definitely reduce the amount of “patch-module” things that are 
> needed to use CXF on Java9.   However, it’s not something to do on 3.2.x as 
> it adds a ton of dependencies that users may need/want to exclude so not a 
> “patch” thing.As part of this, we’d also update to as many dependencies 
> that are module friendly as possible.  We could also have additional 
> source dirs or similar to the tree for Java 9 “cool things”, providing we can 
> still compile with —target=1.8.Another example could possibly be an 
> update to the http client transport to use the Java9 HttpClient.   If run on 
> Java8, we’d stick with URLConnection, on Java9, use HttpClient. 
> 
> I know Java9 supports the “Multi-Release JAR”, but I’m not sure if Maven can 
> handle/generate those yet.   Something else to look into.
> 
> Dan
> 
> 
> 
> 
>> On Nov 15, 2017, at 6:47 AM, Sergey Beryozkin  wrote:
>> 
>> Hi
>> 
>> Should we open a new Java 9 only master soon enough ?
>> 
>> Thanks, Sergey
> 
> -- 
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
> 

Re: New Java 9 master

[Daniel Kulp]

I’d much rather keep master a “8+9” type of thing for a while.I don’t see 
ANYONE moving to Java 9 for production stuff any time soon.

That said, at some point soon, I’d like to make master more “Java 9 Friendly” 
and hopefully release a 3.3 at some point in the future that supports java8, 
but may be more friendly for Java9.Not 100% sure what that would entail, 
but I would definitely be open to the idea of releases being done with Java9 
that would allow additional modules for Java9 users.

It’s kind of similar to how we moved from JAX-WS 2.1 to 2.2.Until we went 
Java7 only, we had a separate profile that added additional src directories and 
such for JAX-WS 2.2.   On Java 5/6, we had to do JAX-WS 2.1 so the code in the 
normal src/main/java directories was all Java5/6 with JAX-WS 2.1.   However, we 
had a separate src/man/jaxws22 source directory that contained the additional 
classes and such that were needed for JAX-WS 2.2.   At release time, we had to 
make sure we used the appropriate JDK/Profile to get that included.   

Now, what does “Java 9 Friendly” entail?   Not really sure.  Off the top of my 
head, I would definitely start by including dependencies for all the javax.* 
API’s.   Example, core depends on JAXB so add the jaxb-api jar.This would 
definitely reduce the amount of “patch-module” things that are needed to use 
CXF on Java9.   However, it’s not something to do on 3.2.x as it adds a ton of 
dependencies that users may need/want to exclude so not a “patch” thing.As 
part of this, we’d also update to as many dependencies that are module friendly 
as possible.  We could also have additional source dirs or similar to the 
tree for Java 9 “cool things”, providing we can still compile with —target=1.8. 
   Another example could possibly be an update to the http client transport to 
use the Java9 HttpClient.   If run on Java8, we’d stick with URLConnection, on 
Java9, use HttpClient. 

I know Java9 supports the “Multi-Release JAR”, but I’m not sure if Maven can 
handle/generate those yet.   Something else to look into.

Dan




> On Nov 15, 2017, at 6:47 AM, Sergey Beryozkin  wrote:
> 
> Hi
> 
> Should we open a new Java 9 only master soon enough ?
> 
> Thanks, Sergey

-- 
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Re: New Java 9 master

[Sergey Beryozkin]

Well, personally I'd like to see CXF being live rather than staying 
stale. CXF 3.2.x was open for more than a year and it has not gone off 
track.
Java 9 will have Flow, which despite your or mine preferences, will 
attract users who would rather work with standard Java 9 API as opposed 
to the popular but specific to the libs RxJava2 and/or Reactor, so it is 
a massive feature...
IMHO CXF dev community is large enough now for the Java 9+ only branch 
to succeed


Sergey
On 16/11/17 16:10, Christian Schneider wrote:

I mean simple in regard to everyday work on the code. The effort would be
mainly in setting up this build once.

I simply had bad experiences in the past with a master that is never
released for a long time. For example there was a camel 3 master for a long
time and it deteriorated more and more over time as people concentrated on
the code that was going into the releases they use on a daily basis. So no
one really cared about a master that everyone knew is not released anytime
(soon).

Personally I even prefer to simply stay on a java 8+9 master until a big
percentage of people switched to java 9. This will not allow us to use java
9 features until then but honestly I personally have no intention to ever
switch to java 9. I will probably wait if java 10 brings anything
convincing.

Christian

2017-11-16 16:57 GMT+01:00 Sergey Beryozkin :


Sorry, looks like a pretty messy and non convincing plan to me.
Simple for users and us ? Seriously ? This would be Java 9 only branch
would be released probably once in at least a year time from now.

Cheers, Sergey

On 16/11/17 15:42, Christian Schneider wrote:


So lets make this a little more concrete. What do we expect that people do
in the Java 9 master?

Java 9 modules -> As Andriy explained this only works when all our
dependencies are Java 9 modules. So this will not be near term.
Java 9 reactive streams. Could be interesting but there is already rxjava
and project reactor. So people have the reactive capabilities already. So
I
am not sure how many people are really interested in this. We can do kind
of a poll on the user list.
I do not think there are any other Java 9 features that are really an
incentive for a java 9 only branch.

So I think the Java 9 only code could be limited to only a few modules.
For
example we could have a REST client with java 9 Flow support.
So how about having a build that checks if the developer has a jdk8. If
yes
then we skip the java 9 modules in the build. If the developer has java 9
we build all modules. We could then do our release with Java 9 but make
sure that most modules can run with java 8 and only the few java 9 modules
require java 9. Not sure if that is possible but it would make our and the
users life a lot simpler than a pure java 9 master.

Christian


2017-11-16 15:02 GMT+01:00 Sergey Beryozkin :

Indeed it will take a long time for a team with the limited resources to

have CXF embracing Java 9. Postponing the start of this long process for
2
years or so and wait for the users to come in and say, when will CXF will
do what SpringBoot with Java 9 can do, is not strategically right move
IMHO.

Have the Java 9 branch, let people spend as much time as needed to play
there, keep going with Java 8+9 in 3.2.1. I don't see where the conflict
is.

Cheers. Sergey

On 16/11/17 13:53, Andriy Redko wrote:

Modules are really far away in the future (IMHO). As per my

understanding, we
could think about real modules only when all our dependencies are
modularized,
which would take quite a lot of time I suppose. The Reactive Streams
part
is
really appealing *BUT* even there we **could** keep the same master for
8
and 9
(http://openjdk.java.net/jeps/238).

Honestly, I am not 100% sure we have to branch off the new master and
keep it
Java 9 only right now. May be the good moment will be when we
discountinue
3.1.x so at least the code will be much easier to cherry-pick?

Best Regards,
  Andriy Redko

CS> I am not sure sure about the need for Java 9 modules. Currently I
see
no
CS> user requesting this. It is also not yet fully clear how these
modules
CS> behave in OSGi. As far as I understood as soon as we start with this
we
CS> have code that is not working in Java 8. As we require every change
to be
CS> done in master first this means we have a lot of back port work. A
Java 9
CS> only master will also make it much harder for Java 8 users to supply
pull
CS> requests as they have to develop and test on java 9 which is not
their
CS> production system.

CS> So I think the current situation with a master that works on Java 9
and
CS> Java 8 is a pretty good situation that we should keep for as long as
CS> possible.
CS> I am not sure how attractive the other Java 9 features are.
Personally I
CS> were really eager to adopt Java 8 because of the closures but I see
no real
CS> need for myself to rush to java 9.

CS> When I remember how reluctant we were when it came to adopting the

Re: New Java 9 master

[Christian Schneider]

I mean simple in regard to everyday work on the code. The effort would be
mainly in setting up this build once.

I simply had bad experiences in the past with a master that is never
released for a long time. For example there was a camel 3 master for a long
time and it deteriorated more and more over time as people concentrated on
the code that was going into the releases they use on a daily basis. So no
one really cared about a master that everyone knew is not released anytime
(soon).

Personally I even prefer to simply stay on a java 8+9 master until a big
percentage of people switched to java 9. This will not allow us to use java
9 features until then but honestly I personally have no intention to ever
switch to java 9. I will probably wait if java 10 brings anything
convincing.

Christian

2017-11-16 16:57 GMT+01:00 Sergey Beryozkin :

> Sorry, looks like a pretty messy and non convincing plan to me.
> Simple for users and us ? Seriously ? This would be Java 9 only branch
> would be released probably once in at least a year time from now.
>
> Cheers, Sergey
>
> On 16/11/17 15:42, Christian Schneider wrote:
>
>> So lets make this a little more concrete. What do we expect that people do
>> in the Java 9 master?
>>
>> Java 9 modules -> As Andriy explained this only works when all our
>> dependencies are Java 9 modules. So this will not be near term.
>> Java 9 reactive streams. Could be interesting but there is already rxjava
>> and project reactor. So people have the reactive capabilities already. So
>> I
>> am not sure how many people are really interested in this. We can do kind
>> of a poll on the user list.
>> I do not think there are any other Java 9 features that are really an
>> incentive for a java 9 only branch.
>>
>> So I think the Java 9 only code could be limited to only a few modules.
>> For
>> example we could have a REST client with java 9 Flow support.
>> So how about having a build that checks if the developer has a jdk8. If
>> yes
>> then we skip the java 9 modules in the build. If the developer has java 9
>> we build all modules. We could then do our release with Java 9 but make
>> sure that most modules can run with java 8 and only the few java 9 modules
>> require java 9. Not sure if that is possible but it would make our and the
>> users life a lot simpler than a pure java 9 master.
>>
>> Christian
>>
>>
>> 2017-11-16 15:02 GMT+01:00 Sergey Beryozkin :
>>
>> Indeed it will take a long time for a team with the limited resources to
>>> have CXF embracing Java 9. Postponing the start of this long process for
>>> 2
>>> years or so and wait for the users to come in and say, when will CXF will
>>> do what SpringBoot with Java 9 can do, is not strategically right move
>>> IMHO.
>>>
>>> Have the Java 9 branch, let people spend as much time as needed to play
>>> there, keep going with Java 8+9 in 3.2.1. I don't see where the conflict
>>> is.
>>>
>>> Cheers. Sergey
>>>
>>> On 16/11/17 13:53, Andriy Redko wrote:
>>>
>>> Modules are really far away in the future (IMHO). As per my
 understanding, we
 could think about real modules only when all our dependencies are
 modularized,
 which would take quite a lot of time I suppose. The Reactive Streams
 part
 is
 really appealing *BUT* even there we **could** keep the same master for
 8
 and 9
 (http://openjdk.java.net/jeps/238).

 Honestly, I am not 100% sure we have to branch off the new master and
 keep it
 Java 9 only right now. May be the good moment will be when we
 discountinue
 3.1.x so at least the code will be much easier to cherry-pick?

 Best Regards,
  Andriy Redko

 CS> I am not sure sure about the need for Java 9 modules. Currently I
 see
 no
 CS> user requesting this. It is also not yet fully clear how these
 modules
 CS> behave in OSGi. As far as I understood as soon as we start with this
 we
 CS> have code that is not working in Java 8. As we require every change
 to be
 CS> done in master first this means we have a lot of back port work. A
 Java 9
 CS> only master will also make it much harder for Java 8 users to supply
 pull
 CS> requests as they have to develop and test on java 9 which is not
 their
 CS> production system.

 CS> So I think the current situation with a master that works on Java 9
 and
 CS> Java 8 is a pretty good situation that we should keep for as long as
 CS> possible.
 CS> I am not sure how attractive the other Java 9 features are.
 Personally I
 CS> were really eager to adopt Java 8 because of the closures but I see
 no real
 CS> need for myself to rush to java 9.

 CS> When I remember how reluctant we were when it came to adopting the
 previous
 CS> java versions like 7 and 8 as minimal requirement I think it makes
 sense to
 CS> do this rather slowly.

Re: New Java 9 master

[Sergey Beryozkin]

If we follow this line of reasoning then we should simply have a single 
branch only in CXF where we'd check Java9, Java 8 and Java 7 modules and 
then do Java 9 or Java 8 or Java 7 releases only from the same branch

and may be this will be simple for the users and for us...

Sergey
On 16/11/17 15:57, Sergey Beryozkin wrote:

Sorry, looks like a pretty messy and non convincing plan to me.
Simple for users and us ? Seriously ? This would be Java 9 only branch 
would be released probably once in at least a year time from now.


Cheers, Sergey
On 16/11/17 15:42, Christian Schneider wrote:
So lets make this a little more concrete. What do we expect that 
people do

in the Java 9 master?

Java 9 modules -> As Andriy explained this only works when all our
dependencies are Java 9 modules. So this will not be near term.
Java 9 reactive streams. Could be interesting but there is already rxjava
and project reactor. So people have the reactive capabilities already. 
So I

am not sure how many people are really interested in this. We can do kind
of a poll on the user list.
I do not think there are any other Java 9 features that are really an
incentive for a java 9 only branch.

So I think the Java 9 only code could be limited to only a few 
modules. For

example we could have a REST client with java 9 Flow support.
So how about having a build that checks if the developer has a jdk8. 
If yes

then we skip the java 9 modules in the build. If the developer has java 9
we build all modules. We could then do our release with Java 9 but make
sure that most modules can run with java 8 and only the few java 9 
modules
require java 9. Not sure if that is possible but it would make our and 
the

users life a lot simpler than a pure java 9 master.

Christian


2017-11-16 15:02 GMT+01:00 Sergey Beryozkin :


Indeed it will take a long time for a team with the limited resources to
have CXF embracing Java 9. Postponing the start of this long process 
for 2
years or so and wait for the users to come in and say, when will CXF 
will
do what SpringBoot with Java 9 can do, is not strategically right 
move IMHO.


Have the Java 9 branch, let people spend as much time as needed to play
there, keep going with Java 8+9 in 3.2.1. I don't see where the 
conflict is.


Cheers. Sergey

On 16/11/17 13:53, Andriy Redko wrote:


Modules are really far away in the future (IMHO). As per my
understanding, we
could think about real modules only when all our dependencies are
modularized,
which would take quite a lot of time I suppose. The Reactive Streams 
part

is
really appealing *BUT* even there we **could** keep the same master 
for 8

and 9
(http://openjdk.java.net/jeps/238).

Honestly, I am not 100% sure we have to branch off the new master and
keep it
Java 9 only right now. May be the good moment will be when we 
discountinue

3.1.x so at least the code will be much easier to cherry-pick?

Best Regards,
 Andriy Redko

CS> I am not sure sure about the need for Java 9 modules. Currently 
I see

no
CS> user requesting this. It is also not yet fully clear how these 
modules
CS> behave in OSGi. As far as I understood as soon as we start with 
this

we
CS> have code that is not working in Java 8. As we require every change
to be
CS> done in master first this means we have a lot of back port work. A
Java 9
CS> only master will also make it much harder for Java 8 users to 
supply

pull
CS> requests as they have to develop and test on java 9 which is not 
their

CS> production system.

CS> So I think the current situation with a master that works on Java 9
and
CS> Java 8 is a pretty good situation that we should keep for as 
long as

CS> possible.
CS> I am not sure how attractive the other Java 9 features are.
Personally I
CS> were really eager to adopt Java 8 because of the closures but I see
no real
CS> need for myself to rush to java 9.

CS> When I remember how reluctant we were when it came to adopting the
previous
CS> java versions like 7 and 8 as minimal requirement I think it makes
sense to
CS> do this rather slowly.

CS> Christian

CS> 2017-11-16 13:31 GMT+01:00 Sergey Beryozkin :

Hi Andriy





I'm only presuming that yes, a Java 9 only master would have to support
the new Java 9 modules system, so I'd say a lot of exciting work 
would

await for the CXF dev community :-)




Cheers, Sergey





On 16/11/17 12:19, Andriy Redko wrote:





Hey Sergey,





Do we have a goal to support Java 9 modules (aka Jigsaw) for

the new master branch? Or we just looking to benefit from the
latest changes in stardand library (as you mentioned, Flow & Co,
collections are also a good example)? Is our current master JDK9
compatible actually (haven't seen successfull builds from
https://builds.apache.org/job/CXF-Master-JDK9) ?




Best Regards,

   Andriy Redko



SB> It's pretty simple really. It's about having a new impetus for 
the CXF

SB> development.



SB> Without a Java 9 only master CXF will be about 

Re: New Java 9 master

[Sergey Beryozkin]

Sorry, looks like a pretty messy and non convincing plan to me.
Simple for users and us ? Seriously ? This would be Java 9 only branch 
would be released probably once in at least a year time from now.


Cheers, Sergey
On 16/11/17 15:42, Christian Schneider wrote:

So lets make this a little more concrete. What do we expect that people do
in the Java 9 master?

Java 9 modules -> As Andriy explained this only works when all our
dependencies are Java 9 modules. So this will not be near term.
Java 9 reactive streams. Could be interesting but there is already rxjava
and project reactor. So people have the reactive capabilities already. So I
am not sure how many people are really interested in this. We can do kind
of a poll on the user list.
I do not think there are any other Java 9 features that are really an
incentive for a java 9 only branch.

So I think the Java 9 only code could be limited to only a few modules. For
example we could have a REST client with java 9 Flow support.
So how about having a build that checks if the developer has a jdk8. If yes
then we skip the java 9 modules in the build. If the developer has java 9
we build all modules. We could then do our release with Java 9 but make
sure that most modules can run with java 8 and only the few java 9 modules
require java 9. Not sure if that is possible but it would make our and the
users life a lot simpler than a pure java 9 master.

Christian


2017-11-16 15:02 GMT+01:00 Sergey Beryozkin :


Indeed it will take a long time for a team with the limited resources to
have CXF embracing Java 9. Postponing the start of this long process for 2
years or so and wait for the users to come in and say, when will CXF will
do what SpringBoot with Java 9 can do, is not strategically right move IMHO.

Have the Java 9 branch, let people spend as much time as needed to play
there, keep going with Java 8+9 in 3.2.1. I don't see where the conflict is.

Cheers. Sergey

On 16/11/17 13:53, Andriy Redko wrote:


Modules are really far away in the future (IMHO). As per my
understanding, we
could think about real modules only when all our dependencies are
modularized,
which would take quite a lot of time I suppose. The Reactive Streams part
is
really appealing *BUT* even there we **could** keep the same master for 8
and 9
(http://openjdk.java.net/jeps/238).

Honestly, I am not 100% sure we have to branch off the new master and
keep it
Java 9 only right now. May be the good moment will be when we discountinue
3.1.x so at least the code will be much easier to cherry-pick?

Best Regards,
 Andriy Redko

CS> I am not sure sure about the need for Java 9 modules. Currently I see
no
CS> user requesting this. It is also not yet fully clear how these modules
CS> behave in OSGi. As far as I understood as soon as we start with this
we
CS> have code that is not working in Java 8. As we require every change
to be
CS> done in master first this means we have a lot of back port work. A
Java 9
CS> only master will also make it much harder for Java 8 users to supply
pull
CS> requests as they have to develop and test on java 9 which is not their
CS> production system.

CS> So I think the current situation with a master that works on Java 9
and
CS> Java 8 is a pretty good situation that we should keep for as long as
CS> possible.
CS> I am not sure how attractive the other Java 9 features are.
Personally I
CS> were really eager to adopt Java 8 because of the closures but I see
no real
CS> need for myself to rush to java 9.

CS> When I remember how reluctant we were when it came to adopting the
previous
CS> java versions like 7 and 8 as minimal requirement I think it makes
sense to
CS> do this rather slowly.

CS> Christian

CS> 2017-11-16 13:31 GMT+01:00 Sergey Beryozkin :

Hi Andriy





I'm only presuming that yes, a Java 9 only master would have to support

the new Java 9 modules system, so I'd say a lot of exciting work would
await for the CXF dev community :-)




Cheers, Sergey





On 16/11/17 12:19, Andriy Redko wrote:





Hey Sergey,





Do we have a goal to support Java 9 modules (aka Jigsaw) for

the new master branch? Or we just looking to benefit from the
latest changes in stardand library (as you mentioned, Flow & Co,
collections are also a good example)? Is our current master JDK9
compatible actually (haven't seen successfull builds from
https://builds.apache.org/job/CXF-Master-JDK9) ?




Best Regards,

   Andriy Redko




SB> It's pretty simple really. It's about having a new impetus for the CXF

SB> development.




SB> Without a Java 9 only master CXF will be about fixing the bugs only.

SB> JAX-WS is done long time ago, next version of JAX-RS will take N
amount
SB> of time to materialize.




SB> Java 9 with its Flow class will let CXF do new work around Reactive

SB> support. It will have new features that only work with Java 9 and
may
SB> give new ideas for the contributions.




SB> 3.2.x is at the start of its 

Re: New Java 9 master

[Christian Schneider]

So lets make this a little more concrete. What do we expect that people do
in the Java 9 master?

Java 9 modules -> As Andriy explained this only works when all our
dependencies are Java 9 modules. So this will not be near term.
Java 9 reactive streams. Could be interesting but there is already rxjava
and project reactor. So people have the reactive capabilities already. So I
am not sure how many people are really interested in this. We can do kind
of a poll on the user list.
I do not think there are any other Java 9 features that are really an
incentive for a java 9 only branch.

So I think the Java 9 only code could be limited to only a few modules. For
example we could have a REST client with java 9 Flow support.
So how about having a build that checks if the developer has a jdk8. If yes
then we skip the java 9 modules in the build. If the developer has java 9
we build all modules. We could then do our release with Java 9 but make
sure that most modules can run with java 8 and only the few java 9 modules
require java 9. Not sure if that is possible but it would make our and the
users life a lot simpler than a pure java 9 master.

Christian


2017-11-16 15:02 GMT+01:00 Sergey Beryozkin :

> Indeed it will take a long time for a team with the limited resources to
> have CXF embracing Java 9. Postponing the start of this long process for 2
> years or so and wait for the users to come in and say, when will CXF will
> do what SpringBoot with Java 9 can do, is not strategically right move IMHO.
>
> Have the Java 9 branch, let people spend as much time as needed to play
> there, keep going with Java 8+9 in 3.2.1. I don't see where the conflict is.
>
> Cheers. Sergey
>
> On 16/11/17 13:53, Andriy Redko wrote:
>
>> Modules are really far away in the future (IMHO). As per my
>> understanding, we
>> could think about real modules only when all our dependencies are
>> modularized,
>> which would take quite a lot of time I suppose. The Reactive Streams part
>> is
>> really appealing *BUT* even there we **could** keep the same master for 8
>> and 9
>> (http://openjdk.java.net/jeps/238).
>>
>> Honestly, I am not 100% sure we have to branch off the new master and
>> keep it
>> Java 9 only right now. May be the good moment will be when we discountinue
>> 3.1.x so at least the code will be much easier to cherry-pick?
>>
>> Best Regards,
>> Andriy Redko
>>
>> CS> I am not sure sure about the need for Java 9 modules. Currently I see
>> no
>> CS> user requesting this. It is also not yet fully clear how these modules
>> CS> behave in OSGi. As far as I understood as soon as we start with this
>> we
>> CS> have code that is not working in Java 8. As we require every change
>> to be
>> CS> done in master first this means we have a lot of back port work. A
>> Java 9
>> CS> only master will also make it much harder for Java 8 users to supply
>> pull
>> CS> requests as they have to develop and test on java 9 which is not their
>> CS> production system.
>>
>> CS> So I think the current situation with a master that works on Java 9
>> and
>> CS> Java 8 is a pretty good situation that we should keep for as long as
>> CS> possible.
>> CS> I am not sure how attractive the other Java 9 features are.
>> Personally I
>> CS> were really eager to adopt Java 8 because of the closures but I see
>> no real
>> CS> need for myself to rush to java 9.
>>
>> CS> When I remember how reluctant we were when it came to adopting the
>> previous
>> CS> java versions like 7 and 8 as minimal requirement I think it makes
>> sense to
>> CS> do this rather slowly.
>>
>> CS> Christian
>>
>> CS> 2017-11-16 13:31 GMT+01:00 Sergey Beryozkin :
>>
>> Hi Andriy

>>>
>> I'm only presuming that yes, a Java 9 only master would have to support
 the new Java 9 modules system, so I'd say a lot of exciting work would
 await for the CXF dev community :-)

>>>
>> Cheers, Sergey

>>>
>> On 16/11/17 12:19, Andriy Redko wrote:

>>>
>> Hey Sergey,
>

>> Do we have a goal to support Java 9 modules (aka Jigsaw) for
> the new master branch? Or we just looking to benefit from the
> latest changes in stardand library (as you mentioned, Flow & Co,
> collections are also a good example)? Is our current master JDK9
> compatible actually (haven't seen successfull builds from
> https://builds.apache.org/job/CXF-Master-JDK9) ?
>

>> Best Regards,
>   Andriy Redko
>

>> SB> It's pretty simple really. It's about having a new impetus for the CXF
> SB> development.
>

>> SB> Without a Java 9 only master CXF will be about fixing the bugs only.
> SB> JAX-WS is done long time ago, next version of JAX-RS will take N
> amount
> SB> of time to materialize.
>

>> SB> Java 9 with its Flow class will let CXF do new work around Reactive
> SB> support. It will have new features that only work with Java 9 and
> may
> SB> give new ideas for 

Re: New Java 9 master

[Sergey Beryozkin]

Indeed it will take a long time for a team with the limited resources to 
have CXF embracing Java 9. Postponing the start of this long process for 
2 years or so and wait for the users to come in and say, when will CXF 
will do what SpringBoot with Java 9 can do, is not strategically right 
move IMHO.


Have the Java 9 branch, let people spend as much time as needed to play 
there, keep going with Java 8+9 in 3.2.1. I don't see where the conflict is.


Cheers. Sergey
On 16/11/17 13:53, Andriy Redko wrote:

Modules are really far away in the future (IMHO). As per my understanding, we
could think about real modules only when all our dependencies are modularized,
which would take quite a lot of time I suppose. The Reactive Streams part is
really appealing *BUT* even there we **could** keep the same master for 8 and 9
(http://openjdk.java.net/jeps/238).

Honestly, I am not 100% sure we have to branch off the new master and keep it
Java 9 only right now. May be the good moment will be when we discountinue
3.1.x so at least the code will be much easier to cherry-pick?

Best Regards,
Andriy Redko

CS> I am not sure sure about the need for Java 9 modules. Currently I see no
CS> user requesting this. It is also not yet fully clear how these modules
CS> behave in OSGi. As far as I understood as soon as we start with this we
CS> have code that is not working in Java 8. As we require every change to be
CS> done in master first this means we have a lot of back port work. A Java 9
CS> only master will also make it much harder for Java 8 users to supply pull
CS> requests as they have to develop and test on java 9 which is not their
CS> production system.

CS> So I think the current situation with a master that works on Java 9 and
CS> Java 8 is a pretty good situation that we should keep for as long as
CS> possible.
CS> I am not sure how attractive the other Java 9 features are. Personally I
CS> were really eager to adopt Java 8 because of the closures but I see no real
CS> need for myself to rush to java 9.

CS> When I remember how reluctant we were when it came to adopting the previous
CS> java versions like 7 and 8 as minimal requirement I think it makes sense to
CS> do this rather slowly.

CS> Christian

CS> 2017-11-16 13:31 GMT+01:00 Sergey Beryozkin :


Hi Andriy



I'm only presuming that yes, a Java 9 only master would have to support
the new Java 9 modules system, so I'd say a lot of exciting work would
await for the CXF dev community :-)



Cheers, Sergey



On 16/11/17 12:19, Andriy Redko wrote:



Hey Sergey,



Do we have a goal to support Java 9 modules (aka Jigsaw) for
the new master branch? Or we just looking to benefit from the
latest changes in stardand library (as you mentioned, Flow & Co,
collections are also a good example)? Is our current master JDK9
compatible actually (haven't seen successfull builds from
https://builds.apache.org/job/CXF-Master-JDK9) ?



Best Regards,
  Andriy Redko



SB> It's pretty simple really. It's about having a new impetus for the CXF
SB> development.



SB> Without a Java 9 only master CXF will be about fixing the bugs only.
SB> JAX-WS is done long time ago, next version of JAX-RS will take N
amount
SB> of time to materialize.



SB> Java 9 with its Flow class will let CXF do new work around Reactive
SB> support. It will have new features that only work with Java 9 and may
SB> give new ideas for the contributions.



SB> 3.2.x is at the start of its life-cycle and will have a couple of
years
SB> at least for it to retire, giving Java 8 support.



SB> 3.1.x has probably 6 months or so left in it, and after it's gone we
SB> will have 3.2.x and 4.0.x or whatever new version is preferred.



SB> Sergey
SB> On 16/11/17 08:15, Dennis Kieselhorst wrote:



On 2017-11-16 07:27, Christian Schneider 

wrote:



I dont think we can already predict when users move to Java 9.
So creating a Java 9 only branch at this time means we have to
maintain two
main branches over a long time.



What is the rationale behind a Java 9 only branch compared to being
Java 9
and Java 8 compatible on master?




I also don't see a good reason to do that at the moment. Let's release
the XJC plugin and users should be able to use CXF with Java 9 or am I
missing something?



Cheers
Dennis






CS> --

Re: Remove obsolete RxJava code and keep RxJava2 only one

[Sergey Beryozkin]

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" <*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, 

Re: Remove obsolete RxJava code and keep RxJava2 only one

[Andriy Redko]

+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" <*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 

Re: New Java 9 master

[Andriy Redko]

Modules are really far away in the future (IMHO). As per my understanding, we 
could think about real modules only when all our dependencies are modularized,
which would take quite a lot of time I suppose. The Reactive Streams part is
really appealing *BUT* even there we **could** keep the same master for 8 and 9
(http://openjdk.java.net/jeps/238). 

Honestly, I am not 100% sure we have to branch off the new master and keep it
Java 9 only right now. May be the good moment will be when we discountinue 
3.1.x so at least the code will be much easier to cherry-pick?

Best Regards,
   Andriy Redko

CS> I am not sure sure about the need for Java 9 modules. Currently I see no
CS> user requesting this. It is also not yet fully clear how these modules
CS> behave in OSGi. As far as I understood as soon as we start with this we
CS> have code that is not working in Java 8. As we require every change to be
CS> done in master first this means we have a lot of back port work. A Java 9
CS> only master will also make it much harder for Java 8 users to supply pull
CS> requests as they have to develop and test on java 9 which is not their
CS> production system.

CS> So I think the current situation with a master that works on Java 9 and
CS> Java 8 is a pretty good situation that we should keep for as long as
CS> possible.
CS> I am not sure how attractive the other Java 9 features are. Personally I
CS> were really eager to adopt Java 8 because of the closures but I see no real
CS> need for myself to rush to java 9.

CS> When I remember how reluctant we were when it came to adopting the previous
CS> java versions like 7 and 8 as minimal requirement I think it makes sense to
CS> do this rather slowly.

CS> Christian

CS> 2017-11-16 13:31 GMT+01:00 Sergey Beryozkin :

>> Hi Andriy

>> I'm only presuming that yes, a Java 9 only master would have to support
>> the new Java 9 modules system, so I'd say a lot of exciting work would
>> await for the CXF dev community :-)

>> Cheers, Sergey

>> On 16/11/17 12:19, Andriy Redko wrote:

>>> Hey Sergey,

>>> Do we have a goal to support Java 9 modules (aka Jigsaw) for
>>> the new master branch? Or we just looking to benefit from the
>>> latest changes in stardand library (as you mentioned, Flow & Co,
>>> collections are also a good example)? Is our current master JDK9
>>> compatible actually (haven't seen successfull builds from
>>> https://builds.apache.org/job/CXF-Master-JDK9) ?

>>> Best Regards,
>>>  Andriy Redko

>>> SB> It's pretty simple really. It's about having a new impetus for the CXF
>>> SB> development.

>>> SB> Without a Java 9 only master CXF will be about fixing the bugs only.
>>> SB> JAX-WS is done long time ago, next version of JAX-RS will take N
>>> amount
>>> SB> of time to materialize.

>>> SB> Java 9 with its Flow class will let CXF do new work around Reactive
>>> SB> support. It will have new features that only work with Java 9 and may
>>> SB> give new ideas for the contributions.

>>> SB> 3.2.x is at the start of its life-cycle and will have a couple of
>>> years
>>> SB> at least for it to retire, giving Java 8 support.

>>> SB> 3.1.x has probably 6 months or so left in it, and after it's gone we
>>> SB> will have 3.2.x and 4.0.x or whatever new version is preferred.

>>> SB> Sergey
>>> SB> On 16/11/17 08:15, Dennis Kieselhorst wrote:

 On 2017-11-16 07:27, Christian Schneider 
> wrote:

>> I dont think we can already predict when users move to Java 9.
>> So creating a Java 9 only branch at this time means we have to
>> maintain two
>> main branches over a long time.

>> What is the rationale behind a Java 9 only branch compared to being
>> Java 9
>> and Java 8 compatible on master?


> I also don't see a good reason to do that at the moment. Let's release
> the XJC plugin and users should be able to use CXF with Java 9 or am I
> missing something?

> Cheers
> Dennis





CS> -- 

Re: Remove obsolete RxJava code and keep RxJava2 only one

[Sergey Beryozkin]

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" <*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 *>

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

Re: Remove obsolete RxJava code and keep RxJava2 only one

[Andriy Redko]

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 
>> *> 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 *>
 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.

Re: New Java 9 master

[Sergey Beryozkin]

Obvious typo there, that yes in a Java 9 only master it won;t work with 
Java 8.


To be honest I don't understand why would CXF dev would be effectively 
frozen which would be the case if no Java 9 master is not opened


Sergey
On 16/11/17 13:09, Sergey Beryozkin wrote:
Yes, in a Java 9 only master it will be expected that it won't work with 
Java 9. I guess it's also about trying to anticipate what the users will 
ask. If someone prefers to avoid Java 9 only then they'd just stay for a 
long time with 3.2.x


Sergey
On 16/11/17 13:02, Christian Schneider wrote:

I am not sure sure about the need for Java 9 modules. Currently I see no
user requesting this. It is also not yet fully clear how these modules
behave in OSGi. As far as I understood as soon as we start with this we
have code that is not working in Java 8. As we require every change to be
done in master first this means we have a lot of back port work. A Java 9
only master will also make it much harder for Java 8 users to supply pull
requests as they have to develop and test on java 9 which is not their
production system.

So I think the current situation with a master that works on Java 9 and
Java 8 is a pretty good situation that we should keep for as long as
possible.
I am not sure how attractive the other Java 9 features are. Personally I
were really eager to adopt Java 8 because of the closures but I see no 
real

need for myself to rush to java 9.

When I remember how reluctant we were when it came to adopting the 
previous
java versions like 7 and 8 as minimal requirement I think it makes 
sense to

do this rather slowly.

Christian

2017-11-16 13:31 GMT+01:00 Sergey Beryozkin :


Hi Andriy

I'm only presuming that yes, a Java 9 only master would have to support
the new Java 9 modules system, so I'd say a lot of exciting work would
await for the CXF dev community :-)

Cheers, Sergey

On 16/11/17 12:19, Andriy Redko wrote:


Hey Sergey,

Do we have a goal to support Java 9 modules (aka Jigsaw) for
the new master branch? Or we just looking to benefit from the
latest changes in stardand library (as you mentioned, Flow & Co,
collections are also a good example)? Is our current master JDK9
compatible actually (haven't seen successfull builds from
https://builds.apache.org/job/CXF-Master-JDK9) ?

Best Regards,
  Andriy Redko

SB> It's pretty simple really. It's about having a new impetus for 
the CXF

SB> development.

SB> Without a Java 9 only master CXF will be about fixing the bugs 
only.

SB> JAX-WS is done long time ago, next version of JAX-RS will take N
amount
SB> of time to materialize.

SB> Java 9 with its Flow class will let CXF do new work around Reactive
SB> support. It will have new features that only work with Java 9 
and may

SB> give new ideas for the contributions.

SB> 3.2.x is at the start of its life-cycle and will have a couple of
years
SB> at least for it to retire, giving Java 8 support.

SB> 3.1.x has probably 6 months or so left in it, and after it's 
gone we

SB> will have 3.2.x and 4.0.x or whatever new version is preferred.

SB> Sergey
SB> On 16/11/17 08:15, Dennis Kieselhorst wrote:


On 2017-11-16 07:27, Christian Schneider 

wrote:


I dont think we can already predict when users move to Java 9.
So creating a Java 9 only branch at this time means we have to
maintain two
main branches over a long time.

What is the rationale behind a Java 9 only branch compared to being
Java 9
and Java 8 compatible on master?



I also don't see a good reason to do that at the moment. Let's 
release
the XJC plugin and users should be able to use CXF with Java 9 or 
am I

missing something?

Cheers
Dennis










--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Re: New Java 9 master

[Sergey Beryozkin]

Yes, in a Java 9 only master it will be expected that it won't work with 
Java 9. I guess it's also about trying to anticipate what the users will 
ask. If someone prefers to avoid Java 9 only then they'd just stay for a 
long time with 3.2.x


Sergey
On 16/11/17 13:02, Christian Schneider wrote:

I am not sure sure about the need for Java 9 modules. Currently I see no
user requesting this. It is also not yet fully clear how these modules
behave in OSGi. As far as I understood as soon as we start with this we
have code that is not working in Java 8. As we require every change to be
done in master first this means we have a lot of back port work. A Java 9
only master will also make it much harder for Java 8 users to supply pull
requests as they have to develop and test on java 9 which is not their
production system.

So I think the current situation with a master that works on Java 9 and
Java 8 is a pretty good situation that we should keep for as long as
possible.
I am not sure how attractive the other Java 9 features are. Personally I
were really eager to adopt Java 8 because of the closures but I see no real
need for myself to rush to java 9.

When I remember how reluctant we were when it came to adopting the previous
java versions like 7 and 8 as minimal requirement I think it makes sense to
do this rather slowly.

Christian

2017-11-16 13:31 GMT+01:00 Sergey Beryozkin :


Hi Andriy

I'm only presuming that yes, a Java 9 only master would have to support
the new Java 9 modules system, so I'd say a lot of exciting work would
await for the CXF dev community :-)

Cheers, Sergey

On 16/11/17 12:19, Andriy Redko wrote:


Hey Sergey,

Do we have a goal to support Java 9 modules (aka Jigsaw) for
the new master branch? Or we just looking to benefit from the
latest changes in stardand library (as you mentioned, Flow & Co,
collections are also a good example)? Is our current master JDK9
compatible actually (haven't seen successfull builds from
https://builds.apache.org/job/CXF-Master-JDK9) ?

Best Regards,
  Andriy Redko

SB> It's pretty simple really. It's about having a new impetus for the CXF
SB> development.

SB> Without a Java 9 only master CXF will be about fixing the bugs only.
SB> JAX-WS is done long time ago, next version of JAX-RS will take N
amount
SB> of time to materialize.

SB> Java 9 with its Flow class will let CXF do new work around Reactive
SB> support. It will have new features that only work with Java 9 and may
SB> give new ideas for the contributions.

SB> 3.2.x is at the start of its life-cycle and will have a couple of
years
SB> at least for it to retire, giving Java 8 support.

SB> 3.1.x has probably 6 months or so left in it, and after it's gone we
SB> will have 3.2.x and 4.0.x or whatever new version is preferred.

SB> Sergey
SB> On 16/11/17 08:15, Dennis Kieselhorst wrote:


On 2017-11-16 07:27, Christian Schneider 

wrote:


I dont think we can already predict when users move to Java 9.
So creating a Java 9 only branch at this time means we have to
maintain two
main branches over a long time.

What is the rationale behind a Java 9 only branch compared to being
Java 9
and Java 8 compatible on master?



I also don't see a good reason to do that at the moment. Let's release
the XJC plugin and users should be able to use CXF with Java 9 or am I
missing something?

Cheers
Dennis

Re: New Java 9 master

[Christian Schneider]

I am not sure sure about the need for Java 9 modules. Currently I see no
user requesting this. It is also not yet fully clear how these modules
behave in OSGi. As far as I understood as soon as we start with this we
have code that is not working in Java 8. As we require every change to be
done in master first this means we have a lot of back port work. A Java 9
only master will also make it much harder for Java 8 users to supply pull
requests as they have to develop and test on java 9 which is not their
production system.

So I think the current situation with a master that works on Java 9 and
Java 8 is a pretty good situation that we should keep for as long as
possible.
I am not sure how attractive the other Java 9 features are. Personally I
were really eager to adopt Java 8 because of the closures but I see no real
need for myself to rush to java 9.

When I remember how reluctant we were when it came to adopting the previous
java versions like 7 and 8 as minimal requirement I think it makes sense to
do this rather slowly.

Christian

2017-11-16 13:31 GMT+01:00 Sergey Beryozkin :

> Hi Andriy
>
> I'm only presuming that yes, a Java 9 only master would have to support
> the new Java 9 modules system, so I'd say a lot of exciting work would
> await for the CXF dev community :-)
>
> Cheers, Sergey
>
> On 16/11/17 12:19, Andriy Redko wrote:
>
>> Hey Sergey,
>>
>> Do we have a goal to support Java 9 modules (aka Jigsaw) for
>> the new master branch? Or we just looking to benefit from the
>> latest changes in stardand library (as you mentioned, Flow & Co,
>> collections are also a good example)? Is our current master JDK9
>> compatible actually (haven't seen successfull builds from
>> https://builds.apache.org/job/CXF-Master-JDK9) ?
>>
>> Best Regards,
>>  Andriy Redko
>>
>> SB> It's pretty simple really. It's about having a new impetus for the CXF
>> SB> development.
>>
>> SB> Without a Java 9 only master CXF will be about fixing the bugs only.
>> SB> JAX-WS is done long time ago, next version of JAX-RS will take N
>> amount
>> SB> of time to materialize.
>>
>> SB> Java 9 with its Flow class will let CXF do new work around Reactive
>> SB> support. It will have new features that only work with Java 9 and may
>> SB> give new ideas for the contributions.
>>
>> SB> 3.2.x is at the start of its life-cycle and will have a couple of
>> years
>> SB> at least for it to retire, giving Java 8 support.
>>
>> SB> 3.1.x has probably 6 months or so left in it, and after it's gone we
>> SB> will have 3.2.x and 4.0.x or whatever new version is preferred.
>>
>> SB> Sergey
>> SB> On 16/11/17 08:15, Dennis Kieselhorst wrote:
>>
>>> On 2017-11-16 07:27, Christian Schneider 
 wrote:

> I dont think we can already predict when users move to Java 9.
> So creating a Java 9 only branch at this time means we have to
> maintain two
> main branches over a long time.
>
> What is the rationale behind a Java 9 only branch compared to being
> Java 9
> and Java 8 compatible on master?
>

 I also don't see a good reason to do that at the moment. Let's release
 the XJC plugin and users should be able to use CXF with Java 9 or am I
 missing something?

 Cheers
 Dennis


>>


-- 
-- 
Christian Schneider
http://www.liquid-reality.de


Computer Scientist
http://www.adobe.com

Re: New Java 9 master

[Sergey Beryozkin]

Hi Freeman

OK, thanks. So we already have 3.2.1 meeting a Java9 + Java8 
requirement, which is great. I haven't even tried to build CXF master 
with Java 9 :-), will try asap...


Cheers, Sergey
On 16/11/17 12:23, Freeman Fang wrote:

Hi Sergey,

Yep, it’s about to use Java9 to build and run CXF 3.2.x with classical java 
“classpath” way. To fully adapt the CXF to use jigsaw module, I think we need a 
JDK9 only branch to work with.

Btw, it’s already in current CXF master(3.2.x-SNAPSHOT). We can build and pass 
all tests with latest  JDK 9.0.1. So CXF 3.2.x have it already. I guess what we 
would do next is fork a 3.2.x-fixes branch based on current master, and change 
the master version to 4.0.0-SNAPSHOT, and this master branch could be the one 
we can experiment with pure JAVA9 new features.

Cheers.
－
Freeman(Yue) Fang

Red Hat, Inc.
FuseSource is now part of Red Hat




On Nov 16, 2017, at 6:26 PM, Sergey Beryozkin  wrote:

Hi Freeman

By the way, what is status of your Java 9 branch, I understand it was really 
about using Java 9 to compile and load CXF 3.2.x ? If so then may be it can be 
merged to 3.2.x ?

Cheers, Sergey


On 16/11/17 06:17, Freeman Fang wrote:

+1
If next CXF major release(3.3 or 4.0) are not going to support JDK8 anymore, 
it’s about the time to create master branch which is for Java9(and the 
successor JDK version which is not very far away). And this also would be easy 
for us to adjust CXF to use the jigsaw module eventually, like to add 
module-info.java  to see how is it going on there.
Best Regards
－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat

On Nov 16, 2017, at 1:03 PM, Andy McCright  wrote:

Hi Sergey,

I'm in favor of the idea.  One thing worth noting is that Java 9 is a very
limited support release.  According to Oracle's support strategy [1], Java
9 will only be supported until March 2018, then they will be releasing Java
10 (aka 18.3) which also will have a short shelf-life.  The next long-term
support release is 18.9 which releases in September.  We'll probably want
the new Java 9 master branch to work with 18.3 as well, then maybe consider
a new master branch for 18.9 some time next year. What do you think?

Thanks,
Andy

[1] http://www.oracle.com/technetwork/java/eol-135779.html

On Wed, Nov 15, 2017 at 5:47 AM, Sergey Beryozkin 
wrote:


Hi

Should we open a new Java 9 only master soon enough ?

Thanks, Sergey

Re: New Java 9 master

[Sergey Beryozkin]

Hi Andriy

I'm only presuming that yes, a Java 9 only master would have to support 
the new Java 9 modules system, so I'd say a lot of exciting work would 
await for the CXF dev community :-)


Cheers, Sergey
On 16/11/17 12:19, Andriy Redko wrote:

Hey Sergey,

Do we have a goal to support Java 9 modules (aka Jigsaw) for
the new master branch? Or we just looking to benefit from the
latest changes in stardand library (as you mentioned, Flow & Co,
collections are also a good example)? Is our current master JDK9
compatible actually (haven't seen successfull builds from
https://builds.apache.org/job/CXF-Master-JDK9) ?

Best Regards,
 Andriy Redko

SB> It's pretty simple really. It's about having a new impetus for the CXF
SB> development.

SB> Without a Java 9 only master CXF will be about fixing the bugs only.
SB> JAX-WS is done long time ago, next version of JAX-RS will take N amount
SB> of time to materialize.

SB> Java 9 with its Flow class will let CXF do new work around Reactive
SB> support. It will have new features that only work with Java 9 and may
SB> give new ideas for the contributions.

SB> 3.2.x is at the start of its life-cycle and will have a couple of years
SB> at least for it to retire, giving Java 8 support.

SB> 3.1.x has probably 6 months or so left in it, and after it's gone we
SB> will have 3.2.x and 4.0.x or whatever new version is preferred.

SB> Sergey
SB> On 16/11/17 08:15, Dennis Kieselhorst wrote:

On 2017-11-16 07:27, Christian Schneider  wrote:

I dont think we can already predict when users move to Java 9.
So creating a Java 9 only branch at this time means we have to maintain two
main branches over a long time.

What is the rationale behind a Java 9 only branch compared to being Java 9
and Java 8 compatible on master?


I also don't see a good reason to do that at the moment. Let's release the XJC 
plugin and users should be able to use CXF with Java 9 or am I missing 
something?

Cheers
Dennis

Re: Remove obsolete RxJava code and keep RxJava2 only one

[Sergey Beryozkin]

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" <*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 *>

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: New Java 9 master

[Freeman Fang]

Hi Sergey,

Yep, it’s about to use Java9 to build and run CXF 3.2.x with classical java 
“classpath” way. To fully adapt the CXF to use jigsaw module, I think we need a 
JDK9 only branch to work with.

Btw, it’s already in current CXF master(3.2.x-SNAPSHOT). We can build and pass 
all tests with latest  JDK 9.0.1. So CXF 3.2.x have it already. I guess what we 
would do next is fork a 3.2.x-fixes branch based on current master, and change 
the master version to 4.0.0-SNAPSHOT, and this master branch could be the one 
we can experiment with pure JAVA9 new features.

Cheers.
－
Freeman(Yue) Fang

Red Hat, Inc. 
FuseSource is now part of Red Hat



> On Nov 16, 2017, at 6:26 PM, Sergey Beryozkin  wrote:
> 
> Hi Freeman
> 
> By the way, what is status of your Java 9 branch, I understand it was really 
> about using Java 9 to compile and load CXF 3.2.x ? If so then may be it can 
> be merged to 3.2.x ?
> 
> Cheers, Sergey
> 
> 
> On 16/11/17 06:17, Freeman Fang wrote:
>> +1
>> If next CXF major release(3.3 or 4.0) are not going to support JDK8 anymore, 
>> it’s about the time to create master branch which is for Java9(and the 
>> successor JDK version which is not very far away). And this also would be 
>> easy for us to adjust CXF to use the jigsaw module eventually, like to add 
>> module-info.java  to see how is it going on there.
>> Best Regards
>> －
>> Freeman(Yue) Fang
>> Red Hat, Inc.
>> FuseSource is now part of Red Hat
>>> On Nov 16, 2017, at 1:03 PM, Andy McCright  
>>> wrote:
>>> 
>>> Hi Sergey,
>>> 
>>> I'm in favor of the idea.  One thing worth noting is that Java 9 is a very
>>> limited support release.  According to Oracle's support strategy [1], Java
>>> 9 will only be supported until March 2018, then they will be releasing Java
>>> 10 (aka 18.3) which also will have a short shelf-life.  The next long-term
>>> support release is 18.9 which releases in September.  We'll probably want
>>> the new Java 9 master branch to work with 18.3 as well, then maybe consider
>>> a new master branch for 18.9 some time next year. What do you think?
>>> 
>>> Thanks,
>>> Andy
>>> 
>>> [1] http://www.oracle.com/technetwork/java/eol-135779.html
>>> 
>>> On Wed, Nov 15, 2017 at 5:47 AM, Sergey Beryozkin 
>>> wrote:
>>> 
 Hi
 
 Should we open a new Java 9 only master soon enough ?
 
 Thanks, Sergey
 

Re: New Java 9 master

[Andriy Redko]

Hey Sergey,

Do we have a goal to support Java 9 modules (aka Jigsaw) for
the new master branch? Or we just looking to benefit from the
latest changes in stardand library (as you mentioned, Flow & Co,
collections are also a good example)? Is our current master JDK9
compatible actually (haven't seen successfull builds from
https://builds.apache.org/job/CXF-Master-JDK9) ?

Best Regards,
Andriy Redko

SB> It's pretty simple really. It's about having a new impetus for the CXF 
SB> development.

SB> Without a Java 9 only master CXF will be about fixing the bugs only. 
SB> JAX-WS is done long time ago, next version of JAX-RS will take N amount 
SB> of time to materialize.

SB> Java 9 with its Flow class will let CXF do new work around Reactive 
SB> support. It will have new features that only work with Java 9 and may 
SB> give new ideas for the contributions.

SB> 3.2.x is at the start of its life-cycle and will have a couple of years 
SB> at least for it to retire, giving Java 8 support.

SB> 3.1.x has probably 6 months or so left in it, and after it's gone we 
SB> will have 3.2.x and 4.0.x or whatever new version is preferred.

SB> Sergey
SB> On 16/11/17 08:15, Dennis Kieselhorst wrote:
>> On 2017-11-16 07:27, Christian Schneider  wrote:
>>> I dont think we can already predict when users move to Java 9.
>>> So creating a Java 9 only branch at this time means we have to maintain two
>>> main branches over a long time.
>>>
>>> What is the rationale behind a Java 9 only branch compared to being Java 9
>>> and Java 8 compatible on master?
>> 
>> I also don't see a good reason to do that at the moment. Let's release the 
>> XJC plugin and users should be able to use CXF with Java 9 or am I missing 
>> something?
>> 
>> Cheers
>> Dennis
>> 

Re: Remove obsolete RxJava code and keep RxJava2 only one

[Andriy Redko]

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 
 *> 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 *>
>> 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

[Sergey Beryozkin]

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" <*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 *>

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: Introduction

[Andriy Redko]

Hi Andrei,

Welcome! Thanks a lot for joining, your contributions 
are very valueable and much appreciated! 

Best Regards,
   Andriy Redko 

AI> Hi,
AI> As requested by Sergey Beryozkin, I'm sending this email to introduce
AI> myself :-)

AI> I'm a Java developer (though in the last year I've been derailed to ext.js
AI> and Python), from Romania, and CXF user and fan.

AI> I also like to keep an eye on the development progress on some of the
AI> frameworks I use (like CXF, Spring or Hibernate), as I find it valuable to
AI> see if there are any bugs that could affect me and also to see how various
AI> features are implemented by people smarter than me :-)
AI> That implies looking at GIT changes and I like to comment if happen to
AI> notice something weird, which triggered the attention of Sergey.

AI> Unfortunately, I rarely have the time to contribute more to the frameworks
AI> I use, in the form of code changes.

AI> Regards,
AI> Andrei

Re: Remove obsolete RxJava code and keep RxJava2 only one

[Andriy Redko]

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"  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>
 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: Introduction

[Sergey Beryozkin]

Hi Andrei

Thank you for the introduction and welcome :-)

Please keep your review comments coming, very much appreciated

Cheers, Sergey
On 16/11/17 11:17, Andrei Ivanov wrote:

Hi,
As requested by Sergey Beryozkin, I'm sending this email to introduce
myself :-)

I'm a Java developer (though in the last year I've been derailed to ext.js
and Python), from Romania, and CXF user and fan.

I also like to keep an eye on the development progress on some of the
frameworks I use (like CXF, Spring or Hibernate), as I find it valuable to
see if there are any bugs that could affect me and also to see how various
features are implemented by people smarter than me :-)
That implies looking at GIT changes and I like to comment if happen to
notice something weird, which triggered the attention of Sergey.

Unfortunately, I rarely have the time to contribute more to the frameworks
I use, in the form of code changes.

Regards,
Andrei

Re: Remove obsolete RxJava code and keep RxJava2 only one

[Sergey Beryozkin]

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"  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>
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

Introduction

[Andrei Ivanov]

Hi,
As requested by Sergey Beryozkin, I'm sending this email to introduce
myself :-)

I'm a Java developer (though in the last year I've been derailed to ext.js
and Python), from Romania, and CXF user and fan.

I also like to keep an eye on the development progress on some of the
frameworks I use (like CXF, Spring or Hibernate), as I find it valuable to
see if there are any bugs that could affect me and also to see how various
features are implemented by people smarter than me :-)
That implies looking at GIT changes and I like to comment if happen to
notice something weird, which triggered the attention of Sergey.

Unfortunately, I rarely have the time to contribute more to the frameworks
I use, in the form of code changes.

Regards,
Andrei

Re: Remove obsolete RxJava code and keep RxJava2 only one

[Andrey Redko]

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 <
>> 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

>>>
>>
>>

Re: New Java 9 master

[Sergey Beryozkin]

Hi Freeman

By the way, what is status of your Java 9 branch, I understand it was 
really about using Java 9 to compile and load CXF 3.2.x ? If so then may 
be it can be merged to 3.2.x ?


Cheers, Sergey


On 16/11/17 06:17, Freeman Fang wrote:

+1

If next CXF major release(3.3 or 4.0) are not going to support JDK8 anymore, 
it’s about the time to create master branch which is for Java9(and the 
successor JDK version which is not very far away). And this also would be easy 
for us to adjust CXF to use the jigsaw module eventually, like to add 
module-info.java  to see how is it going on there.

Best Regards
－
Freeman(Yue) Fang

Red Hat, Inc.
FuseSource is now part of Red Hat




On Nov 16, 2017, at 1:03 PM, Andy McCright  wrote:

Hi Sergey,

I'm in favor of the idea.  One thing worth noting is that Java 9 is a very
limited support release.  According to Oracle's support strategy [1], Java
9 will only be supported until March 2018, then they will be releasing Java
10 (aka 18.3) which also will have a short shelf-life.  The next long-term
support release is 18.9 which releases in September.  We'll probably want
the new Java 9 master branch to work with 18.3 as well, then maybe consider
a new master branch for 18.9 some time next year. What do you think?

Thanks,
Andy

[1] http://www.oracle.com/technetwork/java/eol-135779.html

On Wed, Nov 15, 2017 at 5:47 AM, Sergey Beryozkin 
wrote:


Hi

Should we open a new Java 9 only master soon enough ?

Thanks, Sergey

Re: New Java 9 master

[Sergey Beryozkin]

It's pretty simple really. It's about having a new impetus for the CXF 
development.


Without a Java 9 only master CXF will be about fixing the bugs only. 
JAX-WS is done long time ago, next version of JAX-RS will take N amount 
of time to materialize.


Java 9 with its Flow class will let CXF do new work around Reactive 
support. It will have new features that only work with Java 9 and may 
give new ideas for the contributions.


3.2.x is at the start of its life-cycle and will have a couple of years 
at least for it to retire, giving Java 8 support.


3.1.x has probably 6 months or so left in it, and after it's gone we 
will have 3.2.x and 4.0.x or whatever new version is preferred.


Sergey
On 16/11/17 08:15, Dennis Kieselhorst wrote:

On 2017-11-16 07:27, Christian Schneider  wrote:

I dont think we can already predict when users move to Java 9.
So creating a Java 9 only branch at this time means we have to maintain two
main branches over a long time.

What is the rationale behind a Java 9 only branch compared to being Java 9
and Java 8 compatible on master?


I also don't see a good reason to do that at the moment. Let's release the XJC 
plugin and users should be able to use CXF with Java 9 or am I missing 
something?

Cheers
Dennis

Re: New Java 9 master

[Sergey Beryozkin]

Hi Andy

Right, somewhere around March 2018 would be fine, though, I suppose, 
given this master would be open for a long time, it would be just a 
matter of updating to 18.3 and then to 18.9, I guess by the time a would 
be CXF 4.0.0 gets released at least 18.3  will have already been 
released as well :-)


Cheers, Sergey
On 16/11/17 05:03, Andy McCright wrote:

Hi Sergey,

I'm in favor of the idea.  One thing worth noting is that Java 9 is a very
limited support release.  According to Oracle's support strategy [1], Java
9 will only be supported until March 2018, then they will be releasing Java
10 (aka 18.3) which also will have a short shelf-life.  The next long-term
support release is 18.9 which releases in September.  We'll probably want
the new Java 9 master branch to work with 18.3 as well, then maybe consider
a new master branch for 18.9 some time next year. What do you think?

Thanks,
Andy

[1] http://www.oracle.com/technetwork/java/eol-135779.html

On Wed, Nov 15, 2017 at 5:47 AM, Sergey Beryozkin 
wrote:


Hi

Should we open a new Java 9 only master soon enough ?

Thanks, Sergey

Re: Remove obsolete RxJava code and keep RxJava2 only one

[Sergey Beryozkin]

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

Re: New Java 9 master

[Dennis Kieselhorst]

On 2017-11-16 07:27, Christian Schneider  wrote: 
> I dont think we can already predict when users move to Java 9.
> So creating a Java 9 only branch at this time means we have to maintain two
> main branches over a long time.
> 
> What is the rationale behind a Java 9 only branch compared to being Java 9
> and Java 8 compatible on master?

I also don't see a good reason to do that at the moment. Let's release the XJC 
plugin and users should be able to use CXF with Java 9 or am I missing 
something?

Cheers
Dennis