Neil Bartlett 访谈：关于 OSGi 与新发布的 Bndtools 2.0

Neil Bartlett 是卓越的 OSGi 专家以及流行的 OSGi Eclipse 插件工具 Bndtools 的维护者，他宣布 Bndtools 2.0 已经释放。他强调的一些特性如下：

• 支持 OSGi Release 5 Resolver 以及 Repository 规范
• 导出运行描述符作为单独的可执行文件
• 基线（对于不正确版本的 bundle 会出现构建错误）
• 增强 Semantic Versioning，对于 Consumer 和 Provider 角色使用注解声明
• 导出包装饰
• 改进的增量构建器
• 支持 Apache ACE
• 大量的缺陷修正以及性能提升

这是一个经过漫长等待后的版本释放。之前的版本 1.1 是在 2012 年 3 月释放的。

关于 Bndtools 与 OSGi 的基本情况，InfoQ 与 Neil Bartlett 进行了交流。

对于不了解 OSGi 的读者，您能简单介绍一下 OSGi 与 Bndtools 吗？

OSGi 是在 Java 平台上开发模块化应用程序的一种方式。它允许你构建模块（称之为 bundle），它们彼此之间是隔离的，具备明确的和可管理的依赖。因为我们的关注点在于依赖，所以我们会说特定的 bundle 能不能安装到我们的环境之中，是不是还要添加额外的依赖，它对其他模块的影响是什么等等。

Bndtools 是开发 OSGi bundle 和应用的 IDE。它基于 Eclipse，并且可以通过 Eclipse Marketplace 进行安装。

OSGi 对各种规模和类型的 Java 项目来说，是不是都很重要，还是它适用于较大规模或较小规模的项目？

OSGi 意味着模块化，几乎所有规模的项目都可以从中受益。大型项目为何能够从模块化中受益是非常清楚的：它有助于隔离复杂性并将工作拆分为可管理的部分。即便是小规模的项目也可以从中受益，比如你写了一小段代码并想让它在其他项目中重用。如果你将其开发为 OSGi 的 bundle，那么它更易于重用。

话虽如此，但是对于很小的项目并不真正的需要模块化；例如“Hello World”并不会从模块化方式中受益太多。

OSGi 有一些忠实的追随者，但是似乎缺乏强大的驱动力。这其中的原因是什么？

嗯，这种驱动力在快速增长，但我同意它还不是主流。OSGi 实际上是非常雄心勃勃的，因为它的目标在于改善整个软件开发的过程，因此它对于所有的事情都会产生影响，从代码仓库到测试再到团队结构都是如此。所以，它需要时间来让人们意识到它所带来的好处，对于很多的企业来讲，承担已知的成本来换取未知的预期受益，他们感到紧张也是可以理解的。但是随着越来越多的企业成功使用了它，这种情况正在发生变化。

另外一个问题是技术上的，OSGi 长期以来的工具支持都很差。Bndtools——以及可以与其集成的生态系统工具——正在开始改善这种现状。

现在 Android 赢得了很多的关注，OSGi 与 Android 开发有关系吗？

是的，我认为随着 Android 应用程序的规模越来越大并且越来越复杂，它们也会需要严肃地考虑模块化。OSGi 在很多的 Android 项目中已经获得了成功，但是 Android 与标准的 Java 有明显的不同——以一种微妙但是重要的方式——目前它依然是实验性的领域。

在 OSGi 项目中，Bndtools 是如何提供帮助的？

OSGi 因为难以使用而广受诟病，但是它所需要的只是一些特定的信息，这些信息描述了我们代码的明确声明。这些信息几乎都可以通过封装在 bundle 中的 Java 类来获取……它只是需要被抽取出来。Bndtools 会作为构建过程的一部分来做这些事情，这将使得开发人员只关注自己的代码而无需重复任何在编写在源码的过程中已经做过的事情。

Bndtools 也可以嵌入到 Eclipse 的构建系统之中，这意味在保存一个发生变化的文件之时，你的 bundle 就会构建完成。如果你正在使用 OSGi 的环境（例如调试或测试），那么我们会直接将新的 bundle 放在里面，这借助了 OSGi 运行时动态更新模块的能力。这会促使特别快速的编码 / 运行 / 测试流程，因为你保存代码的时候它基本上就已经在运行了。

在 Bndtools 2.0 的最终版本中，我们添加了对 OSGi Release 5 新的 Resolver 和 Repositories 的支持。这使得你可以关注少量的“顶级（top-level）”模块来组成应用，这些模块提供你的核心功能——resolver 将会负责为核心功能提供所有的静态和运行时依赖。所以你不用再去管理一个很长的要位于类路径中的 JAR 包清单了。

Bndtools 提供协作的工具了吗？

是的。与其他的开发人员协作时，主要的一个困难在于维持共享 API 的兼容性，以及当这些 API 发生变化时该如何进行协调。达到这一点的关键在于合适的版本策略，但是大多数的开发人员在将版本用在制件（artifact）上时，是手工进行的并且相当随意。Bndtools 能够分析你的类并且计算出与之前释放版本的变化。接下来，它会自动为你导出版本。对于 API 的使用者来说，它能够计算出你的代码所能兼容的版本并自动生成这个范围的导入（import）。

有什么竞争对手吗？

可能最接近的竞争对手就是 PDE，也就是插件开发环境（Plug-in Development Environment），它也是基于 Eclipse 的 IDE 但是采取了一种不同的方式。我相信 Bndtools 更好且更有效率，实际上，我之所以如此自信是因为在 Bndtools 存在之前我曾经用过 PDE 很多年。

Eclipse 是必需的吗，或者它能够独立运行吗？你支持其他的 IDE 吗，像 IntelliJ 以及 Netbeans？

有的方面是这样，有的方面却并非如此。Bndtools 基于 bnd 进行构建，bnd 是由 Peter Kriens 开发的。Bnd 是一个没有什么依赖的工具，它可以通过命令行、ANT 或者 Maven 等来进行使用。因此，使用 NetBeans、IDEA 甚至简单文本编辑器的开发人员都可以使用这些项目，因为它们只是会使用 bnd。

Bndtools 确实会需要 Eclipse，它不能直接用于其他的 IDE。但是，这些 IDE 可以通过使用 bnd 本身来构建自己对 OSGi 的支持。大多数的智慧其实来源于 bnd，Bndtools 所做的事情只不过是为 bnd 描述文件提供了漂亮的编辑器、一个 launcher、嵌入到 Eclipse 的构建生命周期等等。

我希望其他的 IDE 也能在这方面做出一些努力，因为我真正希望的是人们使用 OSGi。如果有人不喜欢 Eclipse 的话，我真的无意强迫他们使用它。

除了 Bndtools 手册以外，Bartlett 推荐了 Kirk Knoernschild 的图书《Java Application Architecture》(以前在InfoQ 上曾经介绍过。译者注：该书的中文版由华章图书引进，目前本人正在翻译，读者如有兴趣，敬请期待。) 以及Tim Ward 和Holly Cummins 的《Enterprise OSGi in Action》，后者讨论了OSGi 可选的工具，其中就包括了bnd 和Bndtools，如果想进一步了解的话，它可以作为很好的信息来源。

InfoQ 也曾经推出过一个系列来讨论模块化： Modular Java: What is it? （该文的译文为：模块化Java 简介）, Modular Java: Static Modularity （该文的译文为：模块化Java：静态模块化）, Modular Java: Dynamic Modularity （该文的译文为：模块化Java：动态模块化）以及 Modular Java: Declarative Modularity （该文的译文为：模块化 Java：声明式模块化）。