You can download it from maven central : http://repo1.maven.org/maven2/org/apache/karaf/apache-karaf-minimal/
2016-03-18 19:49 GMT+01:00 Milen Dyankov <[email protected]>: > Oh, got it now. Thanks for clearing this up. Btw, how do I get the minimal > distribution? > > On Fri, Mar 18, 2016 at 7:33 PM, Jean-Baptiste Onofré <[email protected]> > wrote: > > > The shell core headers don't import blueprint, and the shell feature > > doesn't depend to the blueprint feature. > > > > What you see comes from the shell-compat feature which brings the "old" > > blueprint command extender (you are right, for backward compatibility, > this > > feature is installed by default in the Karaf standard distribution). > > > > What I meant is that if you remove the aries-blueprint and shell-compat > > features, Karaf is still running without these dependencies. > > > > Regards > > JB > > > > > > On 03/18/2016 07:24 PM, Milen Dyankov wrote: > > > >> This is what I mean: > >> > >> karaf@root()> bundle:info 44 > >> > >> Apache Karaf :: Shell :: Core (44) > >> > >> ... > >> > >> > >> karaf@root()> bundle:requirements 44 | grep blueprint > >> osgi.wiring.package; > >> > >> > (&(osgi.wiring.package=org.apache.aries.blueprint)(version>=1.5.0)(!(version>=2.0.0))) > >> resolved by: > >> osgi.wiring.package; org.apache.aries.blueprint 1.5.0 from > >> org.apache.aries.blueprint.core [13] > >> osgi.wiring.package; > >> > >> > (&(osgi.wiring.package=org.apache.aries.blueprint.mutable)(version>=1.2.0)(!(version>=2.0.0))) > >> resolved by: > >> osgi.wiring.package; org.apache.aries.blueprint.mutable 1.2.0 from > >> org.apache.aries.blueprint.core [13] > >> osgi.wiring.package; > >> > >> > (&(osgi.wiring.package=org.osgi.service.blueprint)(version>=1.0.0)(!(version>=2.0.0))) > >> resolved by: > >> osgi.wiring.package; org.osgi.service.blueprint 1.0.0 from > >> org.apache.aries.blueprint.core [13] > >> osgi.wiring.package; > >> > >> > (&(osgi.wiring.package=org.osgi.service.blueprint.container)(version>=1.0.0)(!(version>=2.0.0))) > >> resolved by: > >> osgi.wiring.package; org.osgi.service.blueprint.container 1.0.1 from > >> org.apache.aries.blueprint.api [11] > >> osgi.wiring.package; > >> > >> > (&(osgi.wiring.package=org.osgi.service.blueprint.reflect)(version>=1.0.0)(!(version>=2.0.0))) > >> resolved by: > >> osgi.wiring.package; org.osgi.service.blueprint.reflect 1.0.1 from > >> org.apache.aries.blueprint.api [11] > >> > >> > >> > >> On Fri, Mar 18, 2016 at 7:20 PM, Jean-Baptiste Onofré <[email protected]> > >> wrote: > >> > >> Hi Milen, > >>> > >>> Karaf Shell Core (if you mean this bundle) doesn't depend on blueprint > >>> (blueprint is not defined as a <dependency/> and so not in the > manifest, > >>> even for the command extender). > >>> > >>> Regards > >>> JB > >>> > >>> > >>> On 03/18/2016 07:14 PM, Milen Dyankov wrote: > >>> > >>> I personally think DS is pretty much what OSGi Alliance is going to > >>>> promote > >>>> (together with the enRoute project) and from that perspective if any > >>>> component framework's user base is going to grow that would be DS. But > >>>> if > >>>> you guys want to still do it the "hard way" that's fine too. It just > >>>> means > >>>> less people will be able to contribute. > >>>> > >>>> As for things that can not be done with DS, I don't think Christian > >>>> meant > >>>> to say everything must be rewritten! If something needs to be done > >>>> differently (activators/tackers/...) than it can/should be. It's not > all > >>>> or > >>>> nothing scenario IMHO. > >>>> > >>>> Finally about Blueprint. I keep reading in posts that Karaf got rid of > >>>> Blueprint. Meanwhile in 4.0.4 the "Apache Karaf :: Shell :: Core" > still > >>>> depends on Blueprint. So when you say "the bundles in Karaf are > >>>> independent" > >>>> what exactly do you mean? > >>>> > >>>> Best, > >>>> Milen > >>>> > >>>> > >>>> > >>>> On Fri, Mar 18, 2016 at 1:38 PM, Guillaume Nodet <[email protected]> > >>>> wrote: > >>>> > >>>> I agree with Achim and Lukasz. > >>>> > >>>>> > >>>>> Here are the advantages of the current solution: > >>>>> > >>>>> 1/ No additional dependency. One thing that I really care about is > >>>>> that > >>>>> the bundles in Karaf are independent. I.e. they do not rely on an > >>>>> extender. The benefit is that you can upgrade the bundles > >>>>> independently > >>>>> and you don't have an additional bundle which cause all the bundles > to > >>>>> be > >>>>> refreshed / restarted. > >>>>> > >>>>> 2/ Very lightweight. The current framework only consist in 3 classes > : > >>>>> BaseActivator, SingleServiceTracker, > >>>>> SingleServiceTracker$SingleServiceListener. > >>>>> Even the annotations are not included at runtime. > >>>>> > >>>>> 3/ Very fast. No xml parsing, no reflection. Just the > >>>>> OSGI-INF/karaf-tracker/ property file which is loaded by the > activator. > >>>>> So > >>>>> it's really fast at startup. > >>>>> > >>>>> 4/ Very robust. Quite the contrary to what you say, I think this very > >>>>> small > >>>>> framework is way more robust than blueprint or DS. I spent quite > some > >>>>> time > >>>>> load-testing karaf 4 before the release, using the bundle:load-test > >>>>> command. > >>>>> > >>>>> 5/ DS exclusively uses the OSGi registry for wiring. There's no > notion > >>>>> of > >>>>> "internal" wiring, everything is exposed. So by default, the > >>>>> capabilities > >>>>> / requirements contain much more than what is needed, with the > >>>>> additional > >>>>> semantical change where the bundle could be wired to components > coming > >>>>> from > >>>>> different bundles (check the bundle manifest in your branch). > >>>>> > >>>>> So yes, the main drawback are : limited scope and not documented, but > >>>>> given > >>>>> is has never been written to be used outside karaf, I don't see those > >>>>> as > >>>>> real problems. If the concern is users, I'm all for advertising the > >>>>> use > >>>>> of DS or Blueprint for our users, I don't think they should use our > >>>>> internal framework which is much more low level. > >>>>> > >>>>> > >>>>> 2016-03-17 16:43 GMT+01:00 Christian Schneider < > >>>>> [email protected] > >>>>> > >>>>>> : > >>>>>> > >>>>> > >>>>> We currently use some custom Activator base classes to wire the karaf > >>>>> > >>>>>> bundles. The goal of this was to avoid depending on blueprint > >>>>>> as it is a quite heavy dependency and makes it harder to use a > >>>>>> different > >>>>>> blueprint impl or version. > >>>>>> > >>>>>> There are some problems with this approach though: > >>>>>> - It makes it harder for new people to understand what we are doing > >>>>>> - The custom code is more error prone than a proven framework > >>>>>> > >>>>>> So I propose to switch our own bundles to use DS to expose and wire > >>>>>> services. > >>>>>> > >>>>>> There are some advantages: > >>>>>> - The DS annotation approach is easier to understand and more self > >>>>>> documenting than the custom code > >>>>>> - We get rid of the classes in util for the custom code > >>>>>> - The scr commands help diagnose problems > >>>>>> > >>>>>> The main cost is that we need to always install the felix scr > bundle. > >>>>>> > >>>>>> To prove that it can work I switched bundle core in a branch > >>>>>> https://github.com/apache/karaf/tree/EXPERIMENTAL_DS . > >>>>>> The DS based code works quite nicely. > >>>>>> > >>>>>> Btw. I found a small problem with our shell command extender. It > only > >>>>>> seems to work on all commands or none. If there is any required > >>>>>> service > >>>>>> missing then none of the commands is installed. > >>>>>> This made it hard for me to diagnose problems as I was missing all > >>>>>> bundle > >>>>>> commands ;-) > >>>>>> So while working on the switch I thought about two improvements to > the > >>>>>> extender: > >>>>>> 1. Work on each command individually. So each command can activate > as > >>>>>> > >>>>>> soon > >>>>> > >>>>> as the deps are met > >>>>>> 2. Provide a service and commands to diagnose problems like the scr > >>>>>> commands > >>>>>> > >>>>>> Christian > >>>>>> > >>>>>> -- > >>>>>> Christian Schneider > >>>>>> http://www.liquid-reality.de > >>>>>> > >>>>>> Open Source Architect > >>>>>> http://www.talend.com > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> -- > >>>>> ------------------------ > >>>>> Guillaume Nodet > >>>>> ------------------------ > >>>>> Red Hat, Open Source Integration > >>>>> > >>>>> Email: [email protected] > >>>>> Web: http://fusesource.com > >>>>> Blog: http://gnodet.blogspot.com/ > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> -- > >>> Jean-Baptiste Onofré > >>> [email protected] > >>> http://blog.nanthrax.net > >>> Talend - http://www.talend.com > >>> > >>> > >> > >> > >> > > -- > > Jean-Baptiste Onofré > > [email protected] > > http://blog.nanthrax.net > > Talend - http://www.talend.com > > > > > > -- > http://about.me/milen > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected] Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
