Hi Christian, I think this is a good idea, and I was already planning to do this in the next few weeks. There's actually an OSGi standard namespace for extenders called osgi.extender which we should use, and chapter 135.2 of the R5 enterprise specification declares that the blueprint extender should be called osgi.blueprintMy thought was that we should then have capabilities defining various namespace handlers. We'll need a custom namespace for these capabilities, which will be something like "org.apache.aries.blueprint.namespace="<namespace url>".
In addition we'll want to upgrade the maven bundle plugin to add requirements for these sorts of things. The osgi.extender requirement can be on by default, but the aries extension should probably be opt-in. Regards, Tim Ward ------------------- Apache Aries PMC member & Enterprise OSGi advocate Enterprise OSGi in Action (http://www.manning.com/cummins) ------------------- > Date: Fri, 26 Apr 2013 12:11:16 +0200 > From: [email protected] > To: [email protected] > Subject: Idea: Using capabilities to express dependency on blueprint extender > and eventually blueprint namespaces > > Hi all, > > there is one regular problem people face when using blueprint or even > spring dm in the same way. > > The blueprint xml is basically only passive. So if there is no blueprint > extender present then the bundle will go active but will never actually > do something as the blueprint context is never established. The problem > here is that it just silently fails. There is no information that > anything went wrong. > > So I wonder if we could create a capability like org.osgi.blueprint or > org.osgi.blueprint.extender that will be offered by the aries blueprint > extender and will be required by user bundles using blueprint. So the > resolver can tell an admin that he tries to install a blueprint bundle > without also installing a suitable blueprint extender. Of course this > will only make sense if the capbility is universal over blueprint > providers so it would have to be added to the spec. > > As a second step I wonder if this could also be applied to the blueprint > namespaces. There could be a naming scheme for describing blueprint > namespaces as capabilities. So the bundle implementing the namespace > could offer the capability and the bundle using the namespace could > require it. > > Apart from helping the admin diagnosing non working deployments I think > these ideas could even automate deployments. So for example an OBR > resolver could automatically install a blueprint extender or certain > namespace impls if a bundle requires them. > > What do you think? > > Christian > > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com >
