karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Achim Nierbeck <bcanh...@googlemail.com>
Subject Re: Discuss: Use DS for karaf bundles
Date Thu, 17 Mar 2016 16:00:22 GMT
That's the reason we didn't change to DS in the first place ...
so I don't see any reason for changing.

-1

2016-03-17 16:58 GMT+01:00 Morgan <morgan.hautman@gmail.com>:

> 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
>>
>>
>


-- 

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message