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 a different release cycle(like the relationship between CXF and cxf-xjc-utils), and this way our "core" CXF project can offer us more flexibility. Apache Camel has already done the similar thing https://github.com/apache/camel-karaf My 2 cents. Best Regards Freeman On Wed, Mar 2, 2022 at 9:40 PM Jim Ma <mail2ji...@gmail.com> wrote: > 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 > > ./rt/transports/http-jetty/src/main/java/org/apache/cxf/transport/http_jetty/osgi > ./rt/transports/http/src/main/java/org/apache/cxf/transport/http/osgi > ./rt/features/logging/src/main/java/org/apache/cxf/ext/logging/osgi > > ./rt/transports/http-undertow/src/main/java/org/apache/cxf/transport/http_undertow/osgi > > ./services/sts/systests/sts-osgi/src/main/java/org/apache/cxf/systest/sts/osgi > > When CXF moves to support the Jakarta namespace, these should be > changed to support Jakarta internally. But as Andriy Redko figured out on > the https://issues.apache.org/jira/browse/CXF-8371, the > OSGI dependency is one of these blockers. From [1] and [2] OSGI Jakarta > release won't > come in the near future. This made me think if CXF can support Jakarta > with OSGI as optional > for the first step. That means we temporally remove these OSGI code and > add it back when OSGI > Jakarta release is ready. What do you think ? > > [1] https://issues.apache.org/jira/browse/FELIX-6247 > [2] https://issues.apache.org/jira/browse/FELIX-6389 > > Thanks, > Jim >
