为了 Gradle,Spring 摒弃 OSGi

  • Alex Blewitt
  • 滕云

2012 年 11 月 1 日

话题:语言 & 开发

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

作为曾经 OSGi 的坚定拥护者(请见 infoQ 在 2008 年对 Rod Johnson 的采访),SpringSource 开始逐渐远离 OSGi 和模块化技术了。虽然起初,像Srping RooSpring 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 EBREclipse 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)关注我们,并与我们的编辑和其他读者朋友交流。

语言 & 开发