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 different lifecycle (spring, OSGi and friends). Ultimately it can makes sense to move these integrations to the projects they belong to like aries-jaxrs, karaf and spring itself IMHO.
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le jeu. 3 mars 2022 à 14:10, Freeman Fang <freeman.f...@gmail.com> a écrit : > 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 > > >
