Hi Stephan, You are mostly right.
My take on that is that we need a clear position: - Karaf 4.4.x is javax and jdk 17 - Karaf 4.5.x is jakarta and jdk 21 That's clear for the users. It means we will maintain Karaf 4.4.x for a while. Regards JB On Wed, May 6, 2026 at 9:15 AM Siano, Stephan via dev <[email protected]> wrote: > 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 > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>> > > >>> > > > > >
