Yes, no impact for users (exactly as I did on camel-karaf). I’m ready to work on this if we have a consensus.
Regards JB Le ven. 13 déc. 2024 à 19:15, Jamie G. <jamie.goody...@gmail.com> a écrit : > 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 >
