Hi, I fully agree with Grzegorz on this point.
Personally, I would prefer to move away from using cap/req and the full feature resolver entirely in favor of the flat, simple resolver :) The intention behind providing both "Karaf PAX" and "Karaf" is to allow users to choose the distribution that best fits their specific needs. I also agree with Grzegorz that having well-defined versions is far more important and reliable than relying on req/cap; this is precisely why I am advocating for atomic features. We can look at Camel Karaf as a successful example: we define the features ourselves (including wrapping for Camel and CXF) and it works effectively. Regards, JB On Thu, May 7, 2026 at 8:50 AM Grzegorz Grzybek <[email protected]> wrote: > Hello > > Late to the party, but I was triggered by "pax" label ;) > I'm not sure I understand the brand "Karaf Pax"... is it about bringing > ops4j projects into/under Karaf umbrella? > > Speaking from Pax (Pax Logging, Pax Web, Pax URL in that order) - I don't > have clear data about usage of these projects, but I'm sure these are > sometimes used outside of Karaf. > And after I got used to being one of the "old time" maintainers/releasers, > I can admit that somehow I drifted away from caps/reqs approach. Sure - > there are proper headers, but in my experience: > > - these are too incompatible with Maven artifacts (single artifact > version = several libraries - like spring-core, spring-beans, ...) > - in (my) practice (working on JBoss/RedHat Fuse since Fuse 6.1 running > on Karaf 2.3) it's more important to rely on particular version of a > Maven > artifact (assuming proper Export/Import-Package) than on vague notion of > caps/reqs > - CVEs!!!! it changed a lot over last ~10 years and the problem is that > security scanners do not scan packages or caps - they scan Maven > artifacts > > I'm happy Karaf is evolving and I'm happy with any consensus that emerges > ;) > > kind regards > Grzegorz Grzybek > > czw., 7 maj 2026 o 08:16 Jean-Baptiste Onofré <[email protected]> > napisał(a): > > > Cloud distro will have exactly the same features and functionalities as > > Karaf "PAX": the feature resolver is as the full one but not using the > > rep/cap (just reading the features XML without guessing resolution). So, > > users don't have to re-assemble at all: the resolution is still at > runtime > > but without using cap/req (it's basically like it was in Karaf 2.x kind > > of). > > > > Regards > > JB > > > > On Wed, May 6, 2026 at 10:53 PM Łukasz Dywicki <[email protected]> > > wrote: > > > > > Hello, > > > Why not keeping just these two: > > > - Apache Karaf > > > - Apache Karaf Integration (or Mix as Jammie suggested) > > > > > > Having a minimal distro with shell (without ssh), OSGi + logging isn't > a > > > bad idea. That's how OSGi framework usually starts. Still, given how > > > many APIs nowadays apps need, I doubt if it will be used beyond a dry > > run. > > > There is bunch of variants for many of OSGi specs, some of them coming > > > from Eclipse, some from ASF and some from PAX. For example http service > > > can be pax-web, felix-http (or its servlet bridge), or equinox (http or > > > servlet bridge). I don't think its possible to create a variant for > each > > > ecosystem, as number of combinations may grow faster than we can > > > supply them. > > > Having atomic features which Jean mentioned in other thread should > > > really help users who need to assembly their own distribution with bits > > > and pieces they like and work with. > > > > > > The "Cloud" distro with static resolver is basically unusable without > > > re-assembling it with user application. So its better to keep it as > > > documentation / example rather than a release artifact. > > > > > > Best regards, > > > Łukasz Dywicki > > > > > > On 5/6/26 21:57, Jamie G. wrote: > > > > - Karaf PAX > > > > - Karaf > > > > - Karaf Mix > > > > > > > > (easy to see it's a semi continuation of servicemix). > > > > > > > > --Jamie > > > > > > > > On Wed, May 6, 2026 at 2:28 PM Romain Manni-Bucau < > > [email protected]> > > > wrote: > > > >> > > > >> Maybe bus instead of orchestration which has 2-3 other meanings in > > > nowdays > > > >> world? > > > >> > > > >> > > > >> Romain Manni-Bucau > > > >> @rmannibucau <https://x.com/rmannibucau> | .NET Blog > > > >> <https://dotnetbirdie.github.io/> | Blog < > > > https://rmannibucau.github.io/> | Old > > > >> Blog <http://rmannibucau.wordpress.com> | Github > > > >> <https://github.com/rmannibucau> | LinkedIn > > > >> <https://www.linkedin.com/in/rmannibucau> | Book > > > >> < > > > > > > https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064 > > > > > > > >> Javaccino founder (Java/.NET service - contact via linkedin) > > > >> > > > >> Le mer. 6 mai 2026, 18:06, Jean-Baptiste Onofré <[email protected]> a > > > écrit : > > > >> > > > >>> Hi, > > > >>> > > > >>> I understand the reasoning behind those names. My main priority is > > > ensuring > > > >>> that the names are explicit and that "Karaf Cloud" wouldn't be > > > >>> misinterpreted by our users. > > > >>> > > > >>> That being said, I still have a slight preference for the > following: > > > >>> - Karaf PAX > > > >>> - Karaf > > > >>> - Karaf Orchestration > > > >>> > > > >>> Thoughts? > > > >>> > > > >>> Regards, > > > >>> JB > > > >>> > > > >>> On Wed, May 6, 2026 at 4:25 PM Francois Papon < > > > >>> [email protected]> > > > >>> wrote: > > > >>> > > > >>>> My thoughts was that > > > >>>> > > > >>>> - Karaf OSGi => OSGi is used internaly and by users > > > >>>> > > > >>>> - Karaf Cloud => OSGi is used internaly only and not by userrs > > > >>>> > > > >>>> The name "Cloud" was because it's focused on immutable resolver at > > > build > > > >>>> time but I am ok with the others proposals. > > > >>>> > > > >>>> regards, > > > >>>> > > > >>>> François > > > >>>> [email protected] > > > >>>> [email protected] > > > >>>> > > > >>>> Le 06/05/2026 à 15:32, Jean-Baptiste Onofré a écrit : > > > >>>>> Technically, (using your name), both Karaf OSGi and Karaf Cloud > are > > > >>> OSGi > > > >>>>> internally. > > > >>>>> > > > >>>>> Karaf Cloud looks a bit "weird" to me because it isn't > > > cloud-specific. > > > >>>>> > > > >>>>> Mixing your proposal and Romain's proposal, what about: > > > >>>>> > > > >>>>> - Karaf -> Karaf PAX > > > >>>>> - Karaf Simple -> Karaf > > > >>>>> - Karaf Integration -> Karaf Orchestration > > > >>>>> - Karaf Minimal -> delete > > > >>>>> > > > >>>>> Thoughts? > > > >>>>> > > > >>>>> Regards > > > >>>>> JB > > > >>>>> > > > >>>>> On Wed, May 6, 2026 at 1:47 PM Francois Papon < > > > >>>> [email protected]> > > > >>>>> wrote: > > > >>>>> > > > >>>>>> Hi, > > > >>>>>> > > > >>>>>> May be having : > > > >>>>>> > > > >>>>>> - Karaf > Karaf OSGi > > > >>>>>> > > > >>>>>> - Karaf Simple > Karaf Cloud > > > >>>>>> > > > >>>>>> - Karaf Integration > Karaf Orchestration > > > >>>>>> > > > >>>>>> I think tagging the standard distribution as OSGi will help to > > > >>> abstract > > > >>>>>> the OSGi part on the others distribution. > > > >>>>>> > > > >>>>>> regards, > > > >>>>>> > > > >>>>>> François > > > >>>>>> [email protected] > > > >>>>>> [email protected] > > > >>>>>> > > > >>>>>> Le 06/05/2026 à 11:12, Jean-Baptiste Onofré a écrit : > > > >>>>>>> Hi everyone, > > > >>>>>>> > > > >>>>>>> Currently, we provide 3 Karaf distributions: > > > >>>>>>> - Karaf > > > >>>>>>> - Karaf Minimal > > > >>>>>>> - Karaf Integration > > > >>>>>>> > > > >>>>>>> 1. Karaf > > > >>>>>>> This is our standard distribution, packaging the full feature > > > >>>>>>> resolver/service (supporting cap/req), sshd, deployers, > > diagnostic, > > > >>>> kar, > > > >>>>>>> wrapper, etc. > > > >>>>>>> That's the de facto most used distribution. > > > >>>>>>> > > > >>>>>>> 2. Karaf Minimal > > > >>>>>>> This is a very light distribution, packaging the full feature > > > >>>>>>> resolver/service, config, local shell console, ... Hot > > deployment, > > > >>> etc > > > >>>>>> are > > > >>>>>>> not packaged in this distribution by default. > > > >>>>>>> > > > >>>>>>> 3. Karaf Integration > > > >>>>>>> This is based on the Karaf distribution, adding Apache Camel, > > > >>> ActiveMQ > > > >>>>>>> (similar to what was Apache ServiceMix). > > > >>>>>>> > > > >>>>>>> Now, with the new feature service (simple resolver), and the > > Karaf > > > >>>>>> services > > > >>>>>>> (Karaf URL, Karaf Web, etc), I propose creating a new > > distribution > > > >>>>>>> packaging the simple feature service (instead of the full one, > > and > > > >>>>>>> providing Karaf services instead of Pax services. > > > >>>>>>> > > > >>>>>>> I have two questions for you: > > > >>>>>>> 1. Should we keep the Karaf Minimal distribution? I'm not sure > > this > > > >>>>>>> distribution is actually heavily used. > > > >>>>>>> 2. Should we rename Karaf as Karaf "Full" and use Karaf for the > > new > > > >>>>>>> distribution (the one with the simple feature service and Karaf > > > >>>>>> services)? > > > >>>>>>> Or should we keep the Karaf distribution as it is today and > > > >>> introduce a > > > >>>>>> new > > > >>>>>>> distribution "Karaf Simple"? > > > >>>>>>> > > > >>>>>>> Thoughts? > > > >>>>>>> > > > >>>>>>> Regards > > > >>>>>>> JB > > > >>>>>>> > > > >>>> > > > >>> > > > > > > > > >
