cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andriy Redko <>
Subject Re: [DISCUSS] Short term plans/branching....
Date Mon, 19 May 2014 21:46:07 GMT
Hi Dan,

Gotcha, thanks a lot for thorough and detailed explanation.

Best Regards,
    Andriy Redko

DK> On May 19, 2014, at 2:54 PM, Andriy Redko <> 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

DK> I know Willem and I have both been doing a bunch of experiments with Java8.  The main
blocker we have right now is
DK> all the JIBX related stuff as the JIBX plugin cannot work with Java8.  It’s pretty
much out of our hands (and not
DK> really even in the JIBX’s folks hands) as it would require a release of BCEL from
the Apache Commons folks first.  
DK> I *think* if a BCEL release was made, we could at least build CXF with Java8.   That
would leave a couple remaining issues:

DK> CXF’s use of JAXB - we pull in the jaxb-impl and jaxb-xjc from Maven central.   Those
versions have problem with
DK> the secure parsers.   There are two options:  1) wait for Oracle to release new versions
to maven central, or 2)
DK> Update to use the ‘internal’ versions from the JDK.  (or (3), set the system property,
but that sucks)   There might
DK> be another option of doing DOM parsing ourself with Woodstox and just return DOM’s,
but I haven’t looked enough into
DK> JAXB to know if that really would work.   Anyway, #3 on my list was partially to help
with the Java8 issues.  
DK> (note:  this can also be “fixed” by throwing xercesImpl onto the classpath, but
I’m kind of loathe to mandate that as well)

DK> Other third party things:  I’m not sure what the Java8 status is for things like
the version of Spring we use, the version of Jetty, etc….   Definitely a testing effort.

DK> I’m pretty sure most of our tests pass OK with Java8 right now.   It’s mostly just
the build time issues and likely
DK> the DynamicClient (due to invoking JAXB), and any tests that parse/process schemas
(wsdl2java, wadl2java, etc…) that would have issue.

DK> Dan

>> Thanks.

>> Best Regards,
>>    Andriy Redko

>> DK> Just wanted to throw out a quick discussion about how to manage the git repo
for the short term.

>> DK> With the last 2.6.x release, we announced there would be one more release
of that branch.  Thus, we need to keep
>> DK> that branch around.   To avoid having to merge to 3 fixes branches, I’d
like to keep master on 3.0.1 until 2.6.15 is
>> DK> released.   At that point, we can create the 3.0.x-fixes branch and set master
for 3.1.    Is there any problems
>> DK> with that?  Anything needed for 3.1 that needs to be put on master immediately?

>> DK> With 3.0.0 out, I expect a bit higher uptake of it and a possible influx of
issues.   Thus, I’d like a relatively
>> DK> quick turnaround for 3.0.1.  Maybe 4-6 weeks.   At that point, we could do
3.0.1/2.7.12/2.6.15 releases at once and be done with 2.6.x.      Would that work for everyone?

>> DK> Once we start 3.1, I’d like to do a couple things:
>> DK> 1) Update to require Java7
>> DK> 2) Remove all the Jaxws 2.1 support stuff.   With being Java 7, we don’t
need the various 2.2/2.1 profiles and differences and such.
>> DK> 3) *possibly* change the tooling to use the in-JDK JAXB XJC.   With recent
versions of the JDK, the in-JDK versions
>> DK> are actually more up to date than the versions available in central.   Plus,
this would fix some of the issues on
>> DK> Java8.   This MAY cause issue on IBM JDK’s.  Will need to investigate. 
Possible wrap the impl via reflect calls
>> DK> like we do in the runtime.  In any case, this would drop a few dependencies
as well.
>> DK> 4) Start investigating Jetty9 support.   This may be hard without breaking
>> DK> 5) With Java7, start using some of the new interfaces, the AutoClosable one
being the main “nice to have”.

>> DK> Anyway, open for discussion.  :-)

View raw message