Spring抛弃OSGi，转向Gradle

曾经，OSGi的强有力支持者SpringSource已经渐渐抛弃使用OSGi框架和模块化技术。以后，通过EBR的社区支持可能是获得OSGi Spring模块的唯一途径。

SpringSource从一年半前开始由Maven转向使用Gradle来构建系统，Gradle是Groovy的一款开发工具。现在，3.2版已接近尾声，在该版中会停止向Maven Central中生成OSGi元数据。

曾经，OSGi的强有力支持者SpringSource已经渐渐抛弃使用OSGi框架和模块化技术。尽管像Spring Roo（2010年运行在OSGi上）和Spring Dynamic Modules（2008年发布）这些Spring产品在初期都选择使用OSGi生态系统。然而差劲的设计决策，例如试图紧紧地约束依赖包名称和确定确切的版本号（而不是使用导入包这种更加宽容理智的方式来确定版本范围）这些都阻止了对OSGi技术的采用。这些失败的设计在SpringSource EBR上都能活生生地体现。

Spring Dynamic Modules运行时（通过重新编写软件包名称和破坏导入的版本）将重点放在提供多种租赁上，这样产生的问题明显多于解决的商业问题。2009年，Spring DM开始转向Eclipse Foundation，就是最终被大家熟知的Eclipse Virgo。   

自从那时起，Rod Johnson渐渐改变了想法，在去年的年中，他越加意识到OSGi是不适合的。去年年底发布了Spring OSGi元数据并且开始逐步移向Gradle构建系统，不在包含OSGi数据。所有基于3.1构建的服务都将继续包含OSGi数据，这是因为它们采用了Maven工业标准。但是基于3.2构建的新系统中将不会包含OSGi数据，尽管Gradle提供了一个OSGi插件，该插件和Maven Felix BND插件做着相同的事情。

Rob Johnson在年初离开了SpringSource，当时正处于决策和构建系统良好的过渡期，抛弃OSGi可能是SpringSource新管理层决策的一部分。不管怎样，Spring Source EBR和Eclipse Virgo项目都由他们来掌管。以后，通过EBR的社区支持可能是获得OSGi Spring模块的唯一途径，同时，那些背后的防火墙代理商和仅从Maven Central标准中代理资产的人可能都无法得到支持。

你会在意所有的Spring项目里面缺少OSGi元数据吗？广泛采用Gradle并且在Maven Central中减少OSGi内容。对此，你会持何观点呢？