Hi JB- I’m open to solutions, but I think there is a real need to provide users with a clean install of atomic Jakarta API specs by version. Frameworks like ActiveMQ, Camel and CXF often have wide range of compatibility, so a cxf-jaxrs can work with 2 or more Jakarta EE version specs.
End-user pain points: 1. Installing different bundles of the same spec (Geronimo, Jakarta, Tomcat, etc..) 2. Knowing which version of a spec goes with which version of Jakarta EE top-level version 3. Various ‘xml-specs’ or ‘cxf-specs’ features, or provider features that name spec jar by name and version (ex. activemq-client) Concretely, something that has this effect would benefit users: For a Jakarta 11 EE runtime: featuresBoot= jakarta-11-jaxrs, jakarta-11-jms, jakarta-11-transaction, etc.. cxf-jaxrs, activemq-client For a Jakarta 10 EE runtime: featuresBoot= jakarta-10-jaxrs, jakarta-10-jms, jakarta-10-transaction, etc.. cxf-jaxrs, activemq-client Thanks, Matt > On May 2, 2026, at 11:49 PM, Jean-Baptiste Onofré <[email protected]> wrote: > > Hi Matt, > > I agree with the intent, but concretely, the user experience with Cap/Req > is poor and creates significant friction for non-OSGi dependencies, which > is the case for most libraries today. > > Most issues reported regarding the feature resolver stem from Cap/Req. The > purpose of the simple resolver and atomic features is to address exactly > this. I believe atomic features provide a much cleaner approach, even if it > results in more features. For example, camel-karaf uses this method > successfully without any Cap/Req issues. > > We should move toward treating OSGi as an internal mechanism rather than > exposing users to the complexity and difficulties it often causes. > > Regards, > JB > > > On Sat, May 2, 2026 at 7:18 PM Matt Pavlovich <[email protected]> wrote: > >> 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 >>>>> >>>>> >>>>> >>>> >>>> >> >>
