给出两个OSGi捆绑包foo和bar，并且：
bar从Import-Package:导入（foo）包。bar实现了foo中定义的服务。在foo中的服务是否使用（@Reference中的{strong>服务（根据OSGi规范） ）？
从技术上讲，应该首先解决捆绑软件，然后按照满足其依赖关系的顺序启动服务，这在技术上应该是可能的。
（我对某些特定的OSGi实现是否支持它不感兴趣。）
编辑背景：这样，OSGi捆绑包可以为某些库（SPI）提供自定义服务实现
答案 0 :(得分：2)
@Reference是用于服务组件运行时规范的SCR注释。
您必须区分 resolution 阶段（安装捆绑软件并使其成为 的过程）和服务引用接线。
接触SCR组件-您可以想象两个组件，既可以导出（@Service批注）某些服务，又可以相互引用（使用@Reference），这样您就陷入了僵局。
但是您描述的情况似乎还不错。
bar从foo导入软件包-因此在foo之后将其解析。当然，如果您手动安装捆绑软件，然后先安装bar，然后再安装foo，则必须刷新/重新启动bar foo @Reference的{{1}}的服务-这仅意味着SCR运行时将在服务可用后激活bar中的给定SCR组件Karaf使用其功能为功能捆绑包添加了另一层分辨率（标准OSGi解析器）。因此，总比手动安装捆绑软件（或将它们全部放到某个自动部署目录中）要好。
还记得一件事。如果通过某种方式，您的捆绑包获得了foo（或Import-Service）清单标头（它们可能是由maven-bundle-plugin生成的），则解析可能会失败，因为服务通常是在启动捆绑包之后稍后异步注册的。 （使用蓝图或scr运行时）。我个人通常使用以下配置摆脱这些标头：
Require-Capability