All pax libraries we have deployed in Karaf are written without any piece of injection frameworks. Starting from pax logging over pax web, to pax wicket even (it supports blueprint namespaces but does not use it for service tracking).
On other hand, does registration of commands is so hard that could not be done from Activator code? I don't think so. Most critical place which will be affected is actually a tracker, which will need to be registered by us. Indeed we'll get more code to maintain, but that's just matter of good modularization to keep it clean. Honestly, most of complications we have is hiden in service implementations. That's why I do consider dropping of dependency injection framework. It is something which can be done, it's just matter of balance between cons and pros. Best regards, Łukasz Dywicki -- l...@code-house.org Twitter: ldywicki Blog: http://dywicki.pl Code-House - http://code-house.org Wiadomość napisana przez Christian Schneider <ch...@die-schneider.net> w dniu 7 gru 2013, o godz. 13:14: > 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 >
