If the output is a distribution that works for me. We cannot ask the users to do the assembly. In my opinion it’s over engineered compared to distributions as we do today.
Regards JB Le jeu. 7 mai 2026 à 19:13, Matt Pavlovich <[email protected]> a écrit : > 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> > >>>>> > >>> > >> > >> > >
