Eclipse Virgo项目获得批准

作者 Alex Blewitt 译者 张龙 发布于 2010年2月28日 上午9时17分

社区

Java

主题

应用服务器 ,

平台

标签

Eclipse

近日Glyn Normington 宣布Eclipse Virgo项目通过了项目创建的评审 ，现在只等代码导入了；同时VMWare也开始了与Eclipse基金会的合作。

Eclipse Virgo将成为SpringSource dm Server （最近发布了2.0版）的下一版本。基本想法是在适当的代码重构（包括对org.eclipse.virgo包的重命名）后发布2.1版，同时可能会有一些变化。

dm Server和Eclipse Virgo之间主要的区别在于前者基于GPL 3.0 ，而后者基于EPL 1.0 ，这么做会扩大项目的应用范围，Adrian说到 ：

目前的dm Server基于OSGi和Spring Dynamic Modules（现在已经标准化为OSGi Blueprint Service）编程模型为模块化的企业级应用开发提供了极佳的服务器平台。企业级OSGi与dm Server已经取得了长足的进步，但实事求是地说，在企业应用开发中采用OSGi还是需要付出很高的代价的。就像很多新技术一样，一开始的投资需要随着 时间的推移才能得到回报。Hal Hildebrand在其最近的一篇博文中谈到了当前的OSGi价值 。

目前的企业OSGi和dm Server引起了很多人的兴趣，围绕其的创新也一刻没有停止过。这种兴趣尤其以早期的使用者以及那些需求符合OSGi Service Platform动态模块特性的项目为甚。但对于主流的开发团队来说（只希望尽快构建好企业应用，麻烦越少越好），目前采用企业OSGi的代价可能会超出 其短期的收益。在企业OSGi成为主流的企业应用开发方式事实上的标准前需要重点考虑这个问题。

请注意这里我说的是企业应用开发，如果你编写的是基础设施软件并且需要创建“stackless stack（Kirk Knoerschild 、James Governor ）”，那么OSGi已经成为事实上的方法了，得到了dm Server和与之相关的dm kernel子项目的完全支持。

Adrian的评论被一些人断章取义 了，他们认为模块化对于复杂的系统非常奏效，但对于简单的Hello World式的应用却没什么必要，然而OSGi可以帮助我们解决复杂性问题，Kirk Knoerschild在OSGi DevCon London 2010上的演讲中说到 ：

软件的复杂度呈现出指数级的增长。你知道么：

• 在上世纪90年代，一共有1200亿行代码。
• 在本世纪前十年，一共有2500亿行代码。
• 代码行数每过7年就增长一倍。
• 50％的开发时间花在了理解代码上面。
• 90％的软件费用花在了维护和演化上面。

根据以上这些数据我们来看看未来7年将会发生哪些事情。在2010～2017年间，我们所编写的代码量将超过现有的所有代码总量！

除了上面这些因素以外，还有其他一些主要考虑。我们需要一些东西帮助自己理解复杂系统、管理复杂性、简化维护的代价、处理软件系统的自然演化、当系统变大时能处理自然架构变迁。长久以来，我们都缺乏一种中心架构，但这种情况不会持续太久，因为企业将要使用OSGi了！

虽然Virgo已经不太可能成为Eclipse Helios train（将于今夏发布）的一部分了（因为时间上来不及），但新版的dm Server即将发布，如果赶不上3月份的EclipseCon 2010，那应该会在Helios发布前后。

你认为项目的迁移（以及协议的变化）会扩大该产品的应用范围么？