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：声明式模块化）。

相关厂商内容

QCon成都2013大会准备就绪，InfoQ用户免费参加(4.11/12两天)

天猫百度360京东扑鱼达人航班管家等讲师确认参加QCon成都2013

百度复杂系统下的持续部署实践：QCon北京2013

持续集成与持续交付专家乔梁：近十年实战项目案例之深度剖析

每个多任务数据库管理员均须了解的最佳实践

相关赞助商