-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é
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com

Reply via email to