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:53:25 GMT
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 <milendyankov@gmail.com>:

> 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é <jb@nanthrax.net>
> 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é <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
> >>>
> >>>
> >>
> >>
> >>
> > --
> > 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