I went the pure OSGi way for CXF DOSGi. It works but is quite error
prone as you have to handle the dynamics of services and config
yourself. As DOSGi is a pretty small project I think it was worth the
effort for getting rid of DI dependencies.
For karaf I would not like to have to do this for every service and
command bundle. DS might work quite well there.
I have looked into the source from Ioannis. He uses SCR annotations for
the wiring and the felix scr plugin to generate the xml. So it looks
like not to much effort. The learning curve is of course there but I
think with some good example projects it should be relatively easy.
I have not yet seen how the SCR annotations handle config injection. I
hope it works equally well.
Christian
Am 06.12.2013 23:05, schrieb Łukasz Dywicki:
Yes Joed,
You got the point I wanted to reflect. DS and SCR is still dependency which,
for sure, may be optional. Switching to poorer replacement from feature rich
blueprint will bring bigger cost than moving to plain osgi. For me it will look
like stopping in half of the way.
Most of us knows well core spec plus something about blueprint. Very few from
us knows anything more about SCR, except the fact, that it's exists. This kind
of change may decrese number of maintaners to these who already know SCR. From
drawbacks of another DI I may throw that it requires, if I'm not wrong,
additional bundle header which lists all components. Also integration with
maven bundle plugin seems missing. Ie for blueprint we get imports for free and
validation, because when this plugin fails to read XML prevents build from
passing.
The idea of extender, shared earlier in this topic, which install necessary
features is very good. It might be used in similar way as deployers or feature
resolvers to preprocess bundles before installation to automatically enable
certain features.
Łukasz Dywicki
--
Code-House
http://code-house.org
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
