Hi Andriy

Yes, and not for Jakarta: if we want to use HttpService, it's not yet
on Jakarta. But IMHO, we don't have to use the HttpService. We can
have a specific CXF transport directly leveraging the Jetty container
(for instance).
That would simplify the OSGi support and it will work with any Karaf
release (without been coupled to the OSGi HttpService).

About the help, it's always welcome. I propose to start a draft on my
repo and share with you.

Regards
JB

On Fri, Dec 13, 2024 at 8:34 PM Andriy Redko <drr...@gmail.com> wrote:
>
> Hey JB,
>
> Thanks a lot for stepping in and offering your help here. We just recently 
> discussed
> that exact same subject with Colm, which resulted in [1]. From my side, there 
> are few
> questions:
>  - is OSGI ecosystem leveled up on Jakarta? (seems like not fully)
>  - do you need help from CXF folks?
>
> From CXF side, moving the OSGI / Karaf into the separate repo would reduce 
> the maintenance
> burden for sure (leaving aside the fact that now cxf-karaf has to be 
> maintained).
>
> Thanks!
>
> [1] https://issues.apache.org/jira/browse/CXF-9086
>
> Best Regards,
>     Andriy Redko
>
>
> Friday, December 13, 2024, 1:30:16 PM, you wrote:
>
> > 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
>

Reply via email to