cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Freeman Fang <freeman.f...@gmail.com>
Subject Re: [DISCUSS] Short term plans/branching....
Date Tue, 20 May 2014 04:02:25 GMT
+1 for Dan's plan
And for the JiBX with JDK8, how about we just document in the release notes that some optional
components like JiBX won't support JDK8 due to they are kind of obsolete?
-------------
Freeman(Yue) Fang

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



On 2014-5-20, at 上午6:13, Dennis Sosnoski wrote:

> I don't think the JiBX support should be any concern. I haven't been maintaining the
JiBX code for some time, and the Java 8 issue is probably the last nail in the coffin.
> 
> A new release of BCEL might let JiBX limp along a little longer, but BCEL has been obsolete
for a long time. I would have liked to strip out the BCEL usage and replace it with ASM, which
would also have been cause to clean up some of the nastiest code in the project, but without
some financial support that's not going to happen.
> 
> So I'd say just drop JiBX support going forward.
> 
>  - Dennis
> 
> On 05/20/2014 07:26 AM, Daniel Kulp wrote:
>> On May 19, 2014, at 2:54 PM, Andriy Redko<drreta@gmail.com>  wrote:
>> 
>>> >Hi Dan,
>>> >
>>> >Excellent plan! One question though: following recent discussions on the
list,
>>> >there is strong interest in Java 8 support but we know some issues have to
be resolved.
>>> >Do you think we can at least investigate Java 8 support and be ready as much
as we can?
>> I know Willem and I have both been doing a bunch of experiments with Java8.  The
main blocker we have right now is all the JIBX related stuff as the JIBX plugin cannot work
with Java8.  It’s pretty much out of our hands (and not really even in the JIBX’s folks
hands) as it would require a release of BCEL from the Apache Commons folks first.   I*think*
 if a BCEL release was made, we could at least build CXF with Java8.   That would leave a
couple remaining issues:
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message