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
