Using Cap/Req does provide better ability for Karaf assemblers to swap out Eclipse/Glassfish/etc implementations and not have to change the features of things like ActiveMQ/CXF/Camel.
However, I’m more concerned with moving to an approach where projects depend on the named spec api and version vs installing the spec and impl bundles directly. Having all the cxf features require a feature named ‘cxf-specs’ is problematic as it just shoves a bunch of spec and impl jars into the runtime. There is no separation of the spec API and implementation jars. Example: The cxf-jaxrs feature should depend on a jakarta-v11-rest-api feature, and not ‘cxf-specs’ which installs a pile of bundles by version number that may or may not be needed by the services installed. Matt > On May 2, 2026, at 12:01 AM, Jean-Baptiste Onofré <[email protected]> wrote: > > I would use a simpler approach: just atomic and complete features. > > We should stop with the Cap/Req usage that cause too much issues (refresh, > dual chain resolution, etc). > > Regards > J > > On Fri, May 1, 2026 at 6:18 PM Matt Pavlovich <[email protected]> wrote: > >> Re-working the Jakarta spec features to be API/Impl separated will go a >> long way here. Move from “install these x bundles” to “I need Jakarta REST >> spec..” >> >> DRAFT: https://github.com/apache/karaf/pull/1795 >> >>> On May 1, 2026, at 11:06 AM, Holger Friedrich via dev < >> [email protected]> wrote: >>> >>> Hi, >>>> Thoughts? >>> >>> Sounds good, lets go for Karaf 4.5! >>> >>> I have the feeling that getting the transition javax to jakarta >> completed is the biggest challenge for now. A few of the dependencies are >> old and pull in javax packages; a few like hibernate pull in both and might >> be wrapped to drop the old ones. If we do not handle it and start porting >> apps on top of Karaf, we end up with two different bundles in parallel >> (esp. if we have namespace changes as for fasterxml.jackson). >>> >>> Regards, Holger >>> >>> >>> >> >>
