Hi Dan
On 19/05/14 15:45, Daniel Kulp wrote:
Just wanted to throw out a quick discussion about how to manage the git repo
for the short term.
With the last 2.6.x release, we announced there would be one more release of
that branch. Thus, we need to keep 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
released. At that point, we can create the 3.0.x-fixes branch and set master
for 3.1. Is there any problems with that? Anything needed for 3.1 that
needs to be put on master immediately?
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 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?
Once we start 3.1, I’d like to do a couple things:
1) Update to require Java7
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.
3) *possibly* change the tooling to use the in-JDK JAXB XJC. With recent
versions of the JDK, the in-JDK versions are actually more up to date than the
versions available in central. Plus, this would fix some of the issues on
Java8. This MAY cause issue on IBM JDK’s. Will need to investigate.
Possible wrap the impl via reflect calls like we do in the runtime. In any
case, this would drop a few dependencies as well.
4) Start investigating Jetty9 support. This may be hard without breaking
Jetty8.
5) With Java7, start using some of the new interfaces, the AutoClosable one
being the main “nice to have”.
Anyway, open for discussion. :-)
IMHO a very good plan; Branching 3.0.1 will let those who still require
supporting Java 6 start using CXF 3.0.0 and then moving to 3.1.0 faster
Thanks, Sergey
