OSGi：Blueprint是否取代了声明式服务？
OSGi的新R4.2规范描述了Blueprint服务，用于dependency injection和服务连接。
Blueprint是否取代声明性服务（它仍然是规范的一部分），或者它们是否打算一起工作？
蓝图是否已经可用于流行的实现（Felix和Equinox）？
我问自己同样的问题，在与参与该主题的其他人讨论这个问题时，男高音是虽然两者在某种程度上是重叠的，但使用时的用例却截然不同。 DS是一种轻量级解决方案，可以声明性地避免Activators和模型服务依赖。 BP基本上是一个针对企业部署的DI容器。 对于那些不熟悉OSGi动态特性的“常规”Java开发人员来说，这种情况也更常见（隐藏在代理之后）。
实施方面，有两个项目正在进行（所有这些项目都是容器无关，而不是正式发布）。 Spring DM 2.0将提供一个实现（ 2.0.0.M1已包含一个工作实现 ）以及Apache作为其geronimo项目（ 幻灯片 ）的一部分。
根据我在基于Felix的环境中的经验，DS是唯一成熟的dependency injection器，它提供与OSGi Compendium规范的其他部分（如ConfigAdmin）的一致性。
在我看来，Blueprint是OSGi规范中Spring DM的政治包含。
iPojo是基于Java注释而非XML描述符的替代方案，它隐藏了OSGi基础的某些部分。
如果您以前使用过Spring，那么使用Blueprint服务会比较熟悉。 声明性服务不是那么强大，而是在OSGi容器中广泛采用。
另一个问题是蓝图服务 – 据我所知 – 都存在于一个容器中，即蓝图容器 – 而声明性服务在引用它们的包中提供。 特别是对于Equinox，这会导致不同的行为。 当您想要遵守equinox倡导的严格的类加载方法时，DS应该用于蓝图。