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