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?
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
Jetty8.
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. :-)
