OSGi：蓝图与 Spring DM

Posted 2023-02-22

【中文标题】OSGi：蓝图与 Spring DM

【英文标题】：OSGi: Blueprint vs. Spring DM

【发布时间】：2012-04-18 00:33:36

【问题描述】：

我对 Blueprint 和 Spring DM 有点困惑：

我认为是真的：

Spring DM 是 Spring Source 定义的框架 Blueprint 是 OSGi 联盟定义的框架 Blueprint 从 Spring DM 中“借鉴”了许多想法

没有？

我们能否期望这两个框架在未来合而为一（合并）？如果没有，哪一个最有未来的保障？

【参考方案1】：

OSGi 4.2 引入了蓝图服务规范，基于 Spring DM (2.x) 是 Spring Dynamic Modules 项目 参考实现 (RI)。

简而言之：Blueprint 是一种规范，Spring DM 是 Blueprint API 的一种实现

【讨论】：

现在，Spring DM 的继任者 Gemini Blueprint 是 Blueprint API 的参考实现 (source)。

【参考方案2】：

除了 Dmytro Pishchukhin 的回答之外，应该指出 Spring DM 项目在某种程度上是一个死项目，因为 DM 2 从未达到“发布”版本。

取而代之的是contributed to the Eclipse foundation，在那里它变成了Gemini Blueprint project。

【讨论】：

除此之外 =) 还有 Apache Aries，它是 Blueprint 规范的另一个实现。

【参考方案3】：

Blueprint 是在 SpringSource/Interface21 的领导下在 OSGi 联盟中开发的。

但是，如果您正在寻找一种利用 OSGi 的方法，请使用带有注释的声明式服务 (DS)在 包（服务）之间。根据我的经验，当您制作小的内聚包时，您并不真的需要连接 XML。 DS 在处理服务方面比 Blueprint/Spring DM 好得多，因为它们倾向于“隐藏”动态性，而 DS 只是让它变得微不足道。

【讨论】：

@ArchimedesTrajano Declarative Services

谢谢，我刚刚检查了链接，我想我还是倾向于蓝图。

你的选择，只是不要说我警告过你:-)

【参考方案4】：

我的理解是SpringDM is a dead project。检查 GA 和发布日期。因此，尽管它最终对规范的开发做出了很大贡献，但它对类加载器的处理方式很糟糕。 Apache-Aries 是一个强大的蓝图实现。请注意，使用蓝图并不排除使用弹簧。我建议将Karaf 作为一个强大的平台，可以将Eclipse Equinox 或Apache Felix 用于OSGI 引擎。如果您在应用程序级别进行开发，您的服务可能被企业内的其他团队或组织使用，或者被您的客户扩展，我喜欢 blueprint 与 DS。我认为蓝图也更适合传统的企业计算环境。但 DS 或 Ipojo 可能更合适，具体取决于您的特定目标环境。

【讨论】：

您能否分享有关 Spring DM 的“类加载器的糟糕方法”的任何见解/指针？我很好奇后果。

【参考方案5】：

在 Gemini Blueprint 文档的介绍中，他们清楚地解释了区别： http://www.eclipse.org/gemini/blueprint/documentation/reference/1.0.2.RELEASE/html/index.html

我在这里复制：

第 1 章 Spring 动态模块成为 Eclipse Gemini 蓝图

2009 年底，作为 Gemini 项目提案的成员，SpringSource 向 Eclipse 基金会贡献了 Spring Dynamic Modules（也称为 Spring OSGi）项目。 Spring DM v2 代码库连同其问题跟踪器和论坛已移至 Eclipse.org。该项目获得了 Apache 许可和 EPL 的双重许可。

虽然名称已更改，但代码及其功能保持不变。如迁移指南中所述，现有 Spring DM 应用程序可以轻松迁移到 Eclipse Gemini Blueprint。