为了Gradle，Spring摒弃OSGi-InfoQ

一段时间以来， SpringSource 一直为 Gradle （基于 Groovy 语言）构建系统的支持者。在一年半之前，SpringSource 便开始将构建系统从 Maven 转向 Gradle 。现在，Spring 3.2 的开发已经接近尾声，而在此版本中，OSGi 元数据将不会发布到 Maven 库里。这样看来，OSGi 显然是这场转变的受害者。

作为曾经 OSGi 的坚定拥护者（请见infoQ 在2008 年对Rod Johnson 的采访），SpringSource 开始逐渐远离OSGi 和模块化技术了。虽然起初，像 Srping Roo 和 Spring Dynamic Modules 这样的产品都在 OSGi 上有所投资，但是由于 Bundle-Name 所带来的紧依赖和精确版本依赖等问题，对 OSGi 的采用受到了阻碍。这种设计上的失败还将继续存在于 SpringSource EBR 中。

SpringSource 曾经通过重写包名和修改版本化导入的方式来解决 Spring Dynamic Modules 的问题，但是这样所带来的问题比其所解决的问题还多，结果限制了 Spring 在商业领域的采用量。在 2009 年，Spring DM 开始向 Eclipse Foundation 转移，最终的结果变成了 Eclipse Virgo 。

也是从那时开始，Rod Johnson 开始改变自己的观点，于是在去年，他谈到， OSGi 不够简单。去年年末，Spring 在发布中最后一次包含了 OSGi 元数据。在 Spring 3.1 基础上的所有服务都将继续包含 OSGi 元数据，因为 Spring3.1 是根据 Maven 标准来构建的。然而，在最新的 Spring 3.2 将不再包含 OSGi 元数据了。针对此，Gradle 提供了一个 OSGi 插件，该插件的功能与 Maven Felix BND 插件相同。

虽然 Rod Johnson 在今年年初离开了SpringSource ，但是从Maven 到Gradle 的迁移已经就绪，而SpringSource 新的管理层很可能会继续摒弃OSGi。但不管如何， SpringSource EBR 和 Eclipse Virgo 对 OSGi 的依赖像白纸黑字一样写着。将来，要得到兼容 OSGi 的 Spring 模块可能只有通过有社区支持的 EBR 了。而对于那些在防火墙之后或在 Maven 中使用代理的人来说，连享受这样社区支持 EBR 的机会估计都没有了。

你会介意在 Spring 所有的工程摒弃中 OSGi 元数据吗？你会认为 SpringSource 对 Gradle 的进一步采用会减少 Maven Central 中的 OSGi 内容吗？请在下面发表你的评论。

查看英文原文 http://www.infoq.com/news/2012/10/spring-osgi-gradle

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。