karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com.INVALID>
Subject Re: Discuss: Use DS for karaf bundles
Date Thu, 17 Mar 2016 16:37:57 GMT
Perhaps no one would be surprised that I think this is a good idea :-)

david jencks

> On Mar 17, 2016, at 9:06 AM, Christian Schneider <chris@die-schneider.net> wrote:
> 
> I see the issue for blueprint as it is quite heavy weight.
> Scr on the other hand is just one bundle.
> 
> Christian
> 
> On 17.03.2016 16:58, Morgan wrote:
>> I only see one problem.
>> JB wants to keep a normal/default distro where scr could have a place in the distro
and also a minimal distro without scr so I don't know how you would deal with that?
>> 
>> On 2016-03-17 16:43, Christian Schneider wrote:
>>> 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
> 


Mime
View raw message