karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: Discuss: Use DS for karaf bundles
Date Fri, 18 Mar 2016 21:17:05 GMT
It's also available on mirror:

http://www.apache.org/dyn/closer.lua/karaf/4.0.4/apache-karaf-minimal-4.0.4.tar.gz

I will add these links on the website.

Regards
JB

On 03/18/2016 07:53 PM, Guillaume Nodet wrote:
> 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
>>
>
>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Mime
View raw message