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
