If you use the apache-karaf distribution, the compatibility layer is installed. It includes a fragment attached to shell-core that drags in blueprint. Try using the apache-karat-minimal distribution instead. Fwiw, i'm almost exclusively use that one at dev time.
So yes, blueprint is completely optional. I'd like to keep it that way and not add a dependency on a different extender, that wasn't really the point of getting rid of blueprint... 2016-03-18 19:24 GMT+01:00 Milen Dyankov <[email protected]>: > 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 > > > > > > -- > http://about.me/milen > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected] Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
