Correct. That’s my point — store all the etc/ contents for each ‘distro’ in
separate folders and change the ${karaf.etc} as desired vs shipping a separate
runtime.
The startup scripts simply change the value of ${karaf.etc} to point to the
appropriate profile/$foo/etc
Example: Container would flip ‘distros’ by a simple env variable:
KARAF_PROFILE = ‘default | minimal | mix | kservices'
if [[ $KARAF_PROFILE (is not set or) eq ‘default’ ]] then
karaf.etc = etc/
fi
if [[ $KARAF_PROFILE eq ‘kservices’ ]] then
karaf.etc = profiles/kservices/etc/
fi
if [[ $KARAF_PROFILE eq ‘mix’ ]] then
karaf.etc = profiles/mix/etc/
fi
if [[ $KARAF_PROFILE eq ‘minimal’ ]] then
karaf.etc = profiles/minimal/etc/
fi
.. and so on
I think trying to package local offline repositories is a challenge (especially
with Camel). Instead, we can rely on the tooling and examples to ship things
like a ‘apache-cxf-rest-repo’ , ‘apache-activemq-broker-repo’ that is a
local-repo/ folder zipped up that can be injected into a container or overlayed
during assembly.
Matt Pavlovich
> On May 7, 2026, at 11:13 AM, Jean-Baptiste Onofré <[email protected]> wrote:
>
> The etc content is not the same.
>
> Le jeu. 7 mai 2026 à 17:38, Matt Pavlovich <[email protected]> a écrit :
>
>> 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>
>>>>>
>>>
>>
>>
