Example:
Use a cli flag and/or a setenv/env var to flip the ‘profile’ or ${karaf.etc}
etc/ <— default ‘Karaf’ today configurations
profiles/minimal/etc <— karaf minimal
profiles/mix/etc <— karaf mix
profiles/kservices/etc <— Karaf-based services
This would allow for _all_ settings to be swapped in/out— cover system
properties, encrypted properties, cfg files (aka CXF, jetty, etc)
> On May 7, 2026, at 10:00 AM, Matt Pavlovich <[email protected]> wrote:
>
> How about instead of separate distros it is separate profiles or
> configuration ’sets’ within one distribution tar.gz/zip/container? Pax vs
> Karaf services are really just a list of features.
>
> My understanding is that the only difference between Karaf and minimal is the
> boot features. Seems like that could be a property and we could simply have
> different folders of the configurations defined — featuresBoot, feature
> repositories added at boot time, etc.
>
> That would be much easier to manage, document and maintain vs separate
> archives.
>
> -Matt
>
>> On May 7, 2026, at 9:36 AM, Jean-Baptiste Onofré <[email protected]> wrote:
>>
>> Hi,
>>
>> Thanks everyone for your feedback.
>>
>> Here's the latest iteration about distribution names, incorporating your
>> input:
>>
>> - Apache Karaf: same as today ("full" features service, PAX services)
>> - Apache Karaf Minimal: same as today (Apache Karaf but with less boot
>> features)
>> - Apache Karaf Light ("simple" features service, Karaf services)
>> - Apache Karaf Mix (based on Karaf, with ServiceMix flavor, e.g. Camel,
>> ActiveMQ, ...)
>>
>> Does it work for everyone?
>>
>> Thanks!
>>
>> Regards
>> JB
>>
>> On Thu, May 7, 2026 at 3:43 PM Achim Nierbeck <[email protected]>
>> wrote:
>>
>>> Hi JB,
>>>
>>> Thanks for the clarification, from the customer perspective I'd suggest
>>> sticking to the current set for the std. Apache Karaf distribution.
>>> The newer simplified version should be called as such. But as usual finding
>>> names for variables and products is the hardest part in IT, I'll leave this
>>> up to you ;)
>>> Maybe something like "light".
>>> Apache Karaf (TM) light
>>>
>>> Something that indicates by name, that you won't get the full experience
>>> that you've been used to, when using Apache Karaf.
>>>
>>> Again, my two cents from the peanut gallery, just providing the idea of a
>>> customer experience.
>>>
>>> regards, Achim
>>>
>>>
>>> Am Do., 7. Mai 2026 um 14:05 Uhr schrieb Jean-Baptiste Onofré <
>>> [email protected]>:
>>>
>>>> Hi Achim,
>>>>
>>>> The discussion centers on the turnkey distributions we provide to our
>>>> users, whether they use them directly or build upon them. The goal is to
>>>> provide opinionated distributions that better align with specific use
>>>> cases.
>>>>
>>>> I strongly advocate for keeping "Apache Karaf" as the name for the
>>> standard
>>>> distribution.
>>>>
>>>> The main questions are:
>>>>
>>>> 1. Should the standard Apache Karaf distribution now use the "simple"
>>>> features service and Karaf services by default? (Note: users could still
>>>> switch to the "full" service via configuration). If so, should we still
>>>> provide a distribution powered by the "full" feature resolver and Pax
>>>> services as we do today? What should that distribution be named?
>>>>
>>>> 2. Alternatively, should the standard Apache Karaf distribution continue
>>> to
>>>> use the "full" features service and Pax services as it does today? If we
>>>> choose this, should we provide an alternate distribution powered by the
>>>> "simple" features service and Karaf services? What would we name that
>>>> version?
>>>>
>>>> Regards,
>>>> JB
>>>>
>>>> On Thu, May 7, 2026 at 12:01 PM Achim Nierbeck <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> looks like Grzegorz isn't the only one late to the part ;)
>>>>> Let me be the advocatus diaboli:
>>>>>
>>>>> What are you trying to fix that needs fixing?
>>>>> How are our "customers" looking at a name change?
>>>>> What's in it for them?
>>>>>
>>>>> In case this is christal clear for everybody besides me, please proceed
>>>> and
>>>>> I'll go back to the peanut gallery.
>>>>>
>>>>> best regards, Achim
>>>>>
>>>>>
>>>>> Am Do., 7. Mai 2026 um 08:50 Uhr schrieb Grzegorz Grzybek <
>>>>> [email protected]>:
>>>>>
>>>>>> 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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Apache Member
>>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>> Committer
>>>> &
>>>>> Project Lead
>>>>> blog <http://notizblog.nierbeck.de/>
>>>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Apache Member
>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
>>> Project Lead
>>> blog <http://notizblog.nierbeck.de/>
>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>
>
