Thanks for all your detailed analysis, comments and ideas.
Moving the osgi stuff to a seperate repo like github.com/apache/cxf-osgi is
a good idea.
I'll look at this refactoring along with spring after resolving some
javax->jakarta test failures.
I'll push the change to the working branch:
Hello
As long-term OSGi supporter, I'd like to give my +1 for CXF 4.0.0 (?) with
OSGi bits moved to slower-paced github.com/apache/cxf-osgi repo (modules).
As +Jim Ma pointed out, there are several "OSGi
integration points" in CXF with different (including none at all)
dependency in the whole
Hey guys,
Also +1 to @Jim's suggestion, it would also unblock us on supporting latest
JDKs
promptly. Going with something like cxf-karaf integration in separate repository
+ release cycle makes sense to me. @Jim, I know you have started to look at
Spring specifically, but tackling Karaf/OSGi
Hi,
Think it makes sense to split a bit CXF in a strong "core" leveraging
minimal dependency (thinking strongly to servlet there which enables most
of the runtimes from standalone to EE without forgetting microprofile and
OSGi) and extract outside the core project all integrations which have
Hi Jim,
+1 to comment out OSGi bit for now so this won't block the whole Jakarta
namespace migration work on CXF 4.x. And we can move fast without waiting
for the OSGi spec to be JakartaEE9+ compatible.
Going forward, I think we can extract the CXF OSGi/Karaf to a subproject of
CXF, maybe with
Hi,
I took more time to look at more things about Jakarta EE9.x support work
from last week.
Like Spring integration code, now OSGI relevant code is in different maven
modules :
./core/src/main/java/org/apache/cxf/bus/osgi
