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 Thu, 17 Mar 2016 19:15:41 GMT
-0

I'm puzzled here:
- on one hand, I see that it can help for development, improve support 
of scr for some parts of Karaf (shell commands, etc), so it could be a 
good move
- on the other hand, it's a core dependency, as we had for blueprint, so 
with the same problem: even the minimal distribution will require DS/SCR 
support.

Anyway, if we go this way, it will be on a first major release (maybe 
5.x as we removed blueprint from 3.x to 4.x).

Regards
JB

On 03/17/2016 04:43 PM, 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
>

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

Mime
View raw message