Re: New Java 9 master

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?

Re: New Java 9 master

> 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

Re: New Java 9 master

> 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

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

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.

Re: New Java 9 master

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

Re: New Java 9 master

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

Re: New Java 9 master

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,

Re: New Java 9 master

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

Re: New Java 9 master

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

Re: New Java 9 master

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

Re: New Java 9 master

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

Re: New Java 9 master

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

Re: New Java 9 master

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

Re: Remove obsolete RxJava code and keep RxJava2 only one

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

Re: Remove obsolete RxJava code and keep RxJava2 only one

+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

Re: New Java 9 master

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

Re: Remove obsolete RxJava code and keep RxJava2 only one

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

Re: Remove obsolete RxJava code and keep RxJava2 only one

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

Re: New Java 9 master

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

Re: New Java 9 master

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:

Re: New Java 9 master

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

Re: New Java 9 master

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

Re: New Java 9 master

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

Re: Remove obsolete RxJava code and keep RxJava2 only one

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,

Re: New Java 9 master

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

Re: New Java 9 master

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

Re: Remove obsolete RxJava code and keep RxJava2 only one

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

Re: Remove obsolete RxJava code and keep RxJava2 only one

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

Re: Introduction

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

Re: Remove obsolete RxJava code and keep RxJava2 only one

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

Re: Introduction

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

Re: Remove obsolete RxJava code and keep RxJava2 only one

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.

Introduction

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

Re: Remove obsolete RxJava code and keep RxJava2 only one

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

Re: New Java 9 master

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

Re: New Java 9 master

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

Re: New Java 9 master

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

Re: Remove obsolete RxJava code and keep RxJava2 only one

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

Re: New Java 9 master

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