近日 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 发布前后。
你认为项目的迁移（以及协议的变化）会扩大该产品的应用范围么？
察看英文原文： Eclipse Virgo Project Approved
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论