My concern with this approach is that distributions might not be immutable. I think we should offer both to the users.
Regards JB On Fri, May 8, 2026 at 5:23 PM Matt Pavlovich <[email protected]> wrote: > Yes, my proposal is the output would be one distribution with multiple > configuration profiles that the user selects via config or startup. > > > On May 7, 2026, at 10:13 PM, Jean-Baptiste Onofré <[email protected]> > wrote: > > > > 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> > >>>>>>> > >>>>> > >>>> > >>>> > >> > >> > >
