2012-10-24 50 views
6

OSGi Enterprise Release 5規範引入了osgi.extender命名空間。這個命名空間使得假設在框架中安裝擴展器(如Blueprint或Declarative Services)的軟件包可以使用Require-Capability標頭對此依賴關係建模。如何聲明對SCR擴展器功能的要求?

章135.2 osgi.extender命名空間告訴我們的能力爲每個特定擴展的值應該在相應的規範中規定。一個例子,給出了藍圖:

Provide-Capability: osgi.extender; 
    osgi.extender="osgi.blueprint"; 
    uses:="org.osgi.service.blueprint.container,org.osgi.service.blueprint.reflect" 
    version:Version="1.0" 

然而,第112章聲明性服務規範沒有指定一個SCR實現提供的能力。

Peter Kriens給出了一個blog post on Requirements and Capabilities的例子,暗示SCR的能力是osgi.component。我認爲最終這個值將在規範中正確定義。但在那之前我無法使用它。

由於Require-CapabilityProvide-Capability頭是在OSGi的核心版本4.3引入的機制是框架的實現已經可用。所以,我希望我的軟件包能夠表達對SCR的要求,以便可以從OBR存儲庫中解析SCR實現。

我可以想象一個解決方案,我創建一個空包,一方面提供自定義功能,另一方面需要一個實現包。例如:

Provide-Capability: com.example.extender; extender=scr 
Require-Bundle: org.apache.felix.scr; bundle-version=1.6.0 

任何包含聲明性服務的包都可以表達對此功能的需求。例如:

Require-Capability: com.example.extender; filter:="(extender=scr)" 

這是確保在部署包含聲明性服務的捆綁包時解決SCR問題的好方法嗎?有沒有其他方法?

這個問題的一個好的解決方案是一個解決方案,也可以應用到其他不提供功能的傳統軟件包。

回答

4

規範已經定義了osgi.extender命名空間,但各種擴展器規範(Blueprint,DS)需要更新,以強制實施提供適當的擴展器功能。現在,他們可能不會。

因此,現在,您的DS軟件包現在可以「需要」DS實施捆綁包進行解析(甚至安裝)。

OSGi正在爲Blueprint和DS的下一次更新進行工作,這些更新將強制執行osgi.extender功能。

+0

那麼,我建議的解決方法實際上不起作用? –

+3

它會的。您也可以創建一個將該功能添加到DS實施包的片段。 –

+0

太好了,謝謝你的回答! –