Hi, I would like to add one additional aspect to the discussion: The javax->jakarta change is incompatible. What are the plans for the future javax support as there is still some software out that needs the old JEE8 APIs? Will the users of this software be stuck with Karaf 4.4 or will Karaf 4.5 support both namespaces in parallel (or with different features)? If both versions are supported in different versions, wouldn't it be better to name the jakarta version of Karaf 5.0 instead of 4.5 to reflect the incompatible changes?
Best regards Stephan -----Original Message----- From: Jean-Baptiste Onofré <[email protected]> Sent: Tuesday, 5 May 2026 14:19 To: [email protected] Subject: Re: [DISCUSS] Heading to Karaf 4.5.0 Hi Matt, I agree that we need to define the implementation details. However, since GitHub discussions end up on the mailing list anyway, I prefer using a PR combined with mailing list discussion to illustrate the approach. Regarding the Jakarta specs, they should not be boot features; they need to be resolved at runtime by the features that require them. I also believe we should take a more opinionated stance. Since many third parties no longer provide OSGi support, Karaf is effectively in charge. This means Karaf should decide on the spec versions and providers to ensure a consistent experience. Regards, JB On Mon, May 4, 2026 at 5:06 PM Matt Pavlovich <[email protected]> wrote: > Hi François- > > I think we all agree on those principles— the hard part is “How > *exactly*?”. > > Perhaps a GH discussion is in order. > > -Matt > > > On May 4, 2026, at 3:36 AM, Francois Papon > > <[email protected]> > wrote: > > > > Hi, > > > > I'm fully agree with "We should move toward treating OSGi as an > > internal > mechanism rather than exposing users to the complexity and > difficulties it often causes." > > > > OGSi can be used by users if they want or need to, but it should not > > be > mandatory to deploy application in Karaf. > > > > I'm not sure a lot of users has (and want to have) enough knowledge > > on > how OSGi is working (SCR, import/export package, private package, > cap/req....). > > > > About the feature, I think that the jakarta part is mandatory but > > all > others framework integration are an option that we can provide aside > the main distribution. > > > > The purpose should be to have a light baseline runtime and add-on > > like > AMQ, CXF, Camel... > > > > regards, > > > > François > > [email protected] > > [email protected] > > > > Le 03/05/2026 à 06:49, Jean-Baptiste Onofré a écrit : > >> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F% > >>>>> 2Fgithub.com%2Fapache%2Fkaraf%2Fpull%2F1795&data=05%7C02%7Csteph > >>>>> an.siano%40sap.com%7C0ad0250608ca4b579e9a08deaaa0bf5a%7C42f7676c > >>>>> f455423c82f6dc2d99791af7%7C0%7C0%7C639135804574928962%7CUnknown% > >>>>> 7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOi > >>>>> JXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdat > >>>>> a=SdgxxQgeEhrwcFou2CMqNAZuZ4ggS8Q6Vo6TNltF6V0%3D&reserved=0 > >>>>> > >>>>>> 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 > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>> > >
