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 would have more positive impact
on unblocking migration I believe, ready to help you there, thank you!
Best Regards,
Andriy Redko
RMB> Hi,
RMB> Think it makes sense to split a bit CXF in a strong "core" leveraging
RMB> minimal dependency (thinking strongly to servlet there which enables most
RMB> of the runtimes from standalone to EE without forgetting microprofile and
RMB> OSGi) and extract outside the core project all integrations which have
RMB> different lifecycle (spring, OSGi and friends).
RMB> Ultimately it can makes sense to move these integrations to the projects
RMB> they belong to like aries-jaxrs, karaf and spring itself IMHO.
RMB> Romain Manni-Bucau
RMB> @rmannibucau <https://twitter.com/rmannibucau> | Blog
RMB> <https://rmannibucau.metawerx.net/> | Old Blog
RMB> <http://rmannibucau.wordpress.com> | Github
<https://github.com/rmannibucau> |
RMB> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
RMB>
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
RMB> 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
>> >
