For the users, having Camel & CXF 4.x lines available makes a lot of sense - if splitting the work out to a repo to facilitate its maintenance then that's ok.
Will Apache Karaf by default pick up these two repos, making it effectively seamless from the end user point of view? They'll just install Camel and CXF features as per usual? On Fri, Dec 13, 2024 at 12:18 PM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > > Hi folks, > > CXF 4.x first removed the OSGi support (headers), and later re-add > only the headers. > We can consider the OSGi support non-operational in CXF as the > blueprint extension, etc have been removed. > Also, the Apache Karaf support has been removed (e.g. features.xml). > > I think it makes sense to remove this from the CXF "core". > However, I received a bunch of requests from users who want CXF 4.x > running in Karaf (they are "stuck" with CXF 3.x right now). > > In order to provide the best user experience, I would like to propose > the following: > - I propose to completely remove the OSGi support from CXF core > (including the OSGi headers). The CXF modules would be "regular" jar > files, not OSGi bundles > - We can add the OSGi & Karaf support on top on CXF core like we did > with camel-karaf e.g.: > a. We add OSGi bundle "wrapper" > b. We add OSGi extensions (blueprint, bus/endpoint as OSGi service, ...) > c. We add Karaf features repository (e.g. features.xml) > > To host that, I propose to create a cxf-karaf git repository (similar > to https://github.com/apache/camel-karaf) and use the > org.apache.cxf.karaf Maven groupId coordinate). > > Thoughts ? > > Regards > JB
