karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@apache.org>
Subject Re: Discuss: Use DS for karaf bundles
Date Fri, 18 Mar 2016 18:45:33 GMT
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 <milendyankov@gmail.com>:

> 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é <jb@nanthrax.net>
> 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 <gnodet@apache.org>
> >> 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 <
> chris@die-schneider.net
> >>> >:
> >>>
> >>> 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: gnodet@redhat.com
> >>> Web: http://fusesource.com
> >>> Blog: http://gnodet.blogspot.com/
> >>>
> >>>
> >>
> >>
> >>
> > --
> > Jean-Baptiste Onofré
> > jbonofre@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
>
>
>
> --
> http://about.me/milen
>



-- 
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration

Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message