本文来自InfoQ中文站，原文标题：《Bundle.update：Java EE中的OSGi、JSR 294被叫停》。http://www.infoq.com/cn/news/2010/01/state-of-osgi
自从上次的bundle.update发布以来，在OSGi与模块化Java领域中发生了一系列值得我们关注的事件：JSR 294被叫停、Enterprise Expert Group发布了第4个草案、WebSphere上可以直接运行OSGi应用以及即将到来的OSGi大会对预先报名者提供折扣优惠，同时演讲人招募的时间即将截止。
JSR 294被叫停
Sun领导的两个模块化JSR（分别是JSR 294——Java语言改进的模块化支持，以及JSR 277——Java模块化系统）都已被叫停。这样就剩下JCP批准的模块化系统JSR 291（虽然基于有些古老的OSGi 4.1）仍活跃在各种系统中了，其中也包括Sun新近发布的GlassFish v3应用服务器。
我们尚不清楚JSR 294为何会被叫停（JSR 277已经被叫停一年了）。小组收到的上一封邮件表明：
除了实现JSR以外，JDK 7还将提供特定于实现的特性，比如classpath（没有任何一个JSR提过这部分内容）以及Jigsaw模块化系统。
JDK模块化使用了Jigsaw模块化系统。模块化的可见性是由一个原型化的模块info.java文件控制的，这在未来可能会发生变化。模块的私有访问实际上并没有在模块化中使用到，这部分主要是起引导作用的。
关于Jigsaw的进一步讨论将在Jigsaw-dev列表中展开。
简单模块系统自从被提出后就没有什么新进展，尽管版本的事情是由JSR 294控制的，但事实却并非如此，因为其开发过程是在jigsaw-dev邮件列表上进行的，而该邮件列表却游离于JSR 294专家组的邮件列表之外。种种事实表明Jigsaw采取了特定于实现的特性来模块化JDK，虽然这本身是非常好的，但却无法实现编写一次，到处运行的模块。可能以后这都不算什么大事了，因为JDK 7最早也要到2011年才会发布，应用服务器已经将宝压在了OSGi上了。
更新：在本新闻发布后，Alex Buckley证实这种停止实际上是自动的，缘于提案发布的时间而不是说项目就停止开发了。
WebSphere、GlassFish、DM Server以及基于OSGi的服务器
Kirk Knoernschild发文表明一些企业正在构筑自己的OSGi，WebSphere V7 alpha最近就声明可以将OSGi bundle部署到WebSphere中（虽然从2006年开始WebSphere server就已经运行在OSGi内核上了）。
最近发布的GlassFish v3也将OSGi运行时引入到了Sun的Java应用服务器中。尽管GlassFish还不支持直接运行本地的OSGi bundle，但我们可以将其置于Equinox和Felix上，可以在运行着的GlassFish服务器上同时运行其他bundle。
SpringSource的dm Server 2.0.0.M6已经可以运行OSGi web bundle了，借助于其bundle仓库，dm Server指引着企业运行时的前进方向。
Maven 3与Tycho构建、仓库以及Eclipse Marketplace
随着Maven 3（其Tycho可以构建基于OSGi的应用）发布日期的临近，它将成为Eclipse构建EGit以及Tigerstripe的***。
相对于P2仓库来说，Maven仓库的查询能力受到了人们的质疑，但事实上，Maven仓库也可以进行查询。有事实可以证明，Maven仓库是整个Maven构建过程中最为成功的一个方面，它可以根据依赖关系自动下载所需的程序库。从Pack200压缩这个角度来看，P2可能更加高级一些，它还可以更新非JAR组件，然而Mave的über仓库在广度上轻而易举地就超越了Eclipse P2仓库。不仅如此，P2仓库经常被切分成多个独立的仓库，而Maven则具有一个所有项目都可共享的全局仓库。
最近，Eclipse基金会发布了Eclipse Marketplace，它源自于成功的Eclipse插件中心2站点。最初建立EPIC的目的是提供一个中央下载站点，为那些不在Eclipse.org站点上的流行插件提供下载服务，比如Findbugs和Checkstyle。
Eclipse基金会在2006年购买了EPIC的使用权，但后来就基本没再动过它，直到最近开发出了Eclipse Marketplace后这一点才有所改观。在这段时间内，由于缺乏统一的下载结构以及从Update Site到P2的转变极大地限制了中央下载站点（用于搜索及下载插件）的发展势头。
除了插件以外，新的Marketplace还托管了RCP应用（既有商业的，也有免费的）以及培训与咨询供应商。
***要说的是IntelliJ 9的发布，其社区版与商业版都提供了对OSGi应用的支持。由于该***Java IDE可以在本地构建OSGi应用，同时对OSGi应用又提供了巨大的支持，开发模块化Java应用变得***的简单。
OSGi 4.2 EEG草案发布
最近Enterprise Expert Group发布了第4个草案。EEG的目的是定义一套规范以便JEE风格的应用可以作为本地bundle运行在OSGi运行时中。
现在Web应用可以作为bundle使用了。这样不仅使得OSGi运行时能够托管WAR（与Jetty之类的服务器一样），同时WAR还可以在运行时中拥有版本依赖。Pax Web早就可以实现这一点了，但现在形成了标准，任何OSGi运行时都可以使用了。
OSGi框架中对bundle的JMX控制，对于核心OSGi服务的标准化绑定，比如Package Admin以及Cofniguration Admin等等。
事务已经作为JTA绑定的一部分，这样就可以从OSGi服务中获取事务了。
JNDI访问既可以从OSGi中获取，也可以在OSGi服务间得到。
兼容于OSGi的JDBC工厂（与Class.forName()不同）。
凭借这些服务，企业应用可以运行在OSGi环境中而无需完整的JEE栈。尽管JEE 6已经发布，但它有可能是***获得批准的几个JSR之一，Mark Reinhold如是说：
Q：现在为何不开启一个closures JSR，让专家组完成提案工作？
#t#A：到目前为止Project Coin还没有一个JSR，原因与此类似，直到JCP执行委员会内部的争论平息之后才有可能提出新的Java SE JSR。
即将到来的OSGi大会
伦敦将于今年1月23日举办OSGi DevCon London，同时还将举办JAX London。现在，大会的议程已经确定下来了，Kirk Knoernschild将进行主题演讲。
Santa Clara将于今年的3月22——25日举办OSGi DevCon，同时还有 EclipseCon 2010。Robert “Bob大叔” Martin将进行主题演讲。目前还在招募演讲者，如果你有这方面的想法，请递交你的提案。
