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://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 >>>>>> >>>>>> >>>>>> >>>>> >>>
