OSGi 放弃了 Snapshot 提议

  • Alex Blewitt
  • 王丽娟

2012 年 4 月 20 日

话题:语言 & 开发

OSGi 联盟最近发布了OSGi R5 的预览文档。在这个即将发布的规范里,最令人期待的功能之一是鉴于 SNAPSHOT 对现有工具的影响,规范去掉了 SNAPSHOT 风格的版本:

与现有工具、管理和配置系统之间的交互很让人担心。这些系统处理不了带有预发布(也就是 SNAPSHOT)版本字符串的 Bundle。它们要做很多修改才能正确处理预发布版本的语法。

问题的根源在于,Maven(以及与 Maven 兼容的解析程序和构建系统,比如 Ivy 和 Gradle)和 OSGi 对空标识符的处理方式恰恰相反。在 Maven 里,1.2.3.2012 <= 1.2.3,但在 OSGi 里,1.2.3.2012 >= 1.2.3

假如构建的组件既要在非 OSGi 环境里工作(比如使用 Maven)、又要在 OSGi 容器里运行,这就会带来问题。Maven 的惯例是处理很多个2.1-SNAPSHOT,然后才把版本替换成2.1。Artifactory 或 Nexus 等仓库管理器通常则是在发布的时候把快照重写到过时的文件里,以保证可追溯性。

Eclipse PDE Build 和 Maven Tycho 在构建组件时,则会明确指定组件的名称,通常也会把不断变化的日期 / 时间戳作为构建的一部分。由于要构建的所有组件都有新的名称,所以版本可能会增量安装到 OSGi 运行时环境里,新的版本会覆盖另一个。

不幸的是,这意味着“最终”版的组件也包含构建标识符,这些标识符在某些情况下比制品的名称还要长(比如org.junit_4.8.2.v4_8_2_v20110321-1705)。标识符的格式也不一致(例如org.eclipse.jdt.ui_3.7.1.r371_v20110824-0800.jar)。

SpringSource 等一些生产者创建的版本形式则是1.2.3.M1、1.2.3.M2、1.2.3.RELEASE,它们既能用于 OSGi,也能用于 Maven。

OSGi 之前想支持-SNAPSHOT风格的版本,来解决这个问题。有人提议改进Bundle-Version的语法,允许1.2.3-4561.2.3小,Equinox 已经这么实现了。这能让 Bundle 开发者在开发时使用-SNAPSHOT风格的变量(Tycho 和 PDE 等工具都把-SNAPSHOT当成是“神奇的替换值”,而没用使用“.qualifier”),然后再发布1.2.3作为此序列的唯一构建版本,接着又会突然变成1.2.4-SNAPSHOT

很不幸,这种解决方式是臆测出来的,并没有实证依据:

除此之外,我们开始关注预发布版本的复杂度。在 CPEG 里展开讨论、与同行进行沟通的时候,大家都弄不明白版本的顺序,也搞不清楚有些版本是否包含在特定的范围内。如果我们这些“专家”都不能时刻保持清醒,那我们也不用指望别人能很容易地理解。

这种混乱与怎样界定构建范围是有关系的。我们看一下现有情况,以[1.0,2.0)为例,这个区间的1.0表示允许1.0-*的快照版本,而2.0则表示不能出现2.0-*的快照版本。归结起来就是,闭区间包含快照、开区间不包含快照,这似乎很难记。

这个决定实际上不利于推广用 OSGi 生成的内容。大概在一年前,大家对如何在 Maven 名字空间里表示 Eclipse 构建的制品展开了讨论,结论是把组件映射成org.eclipse.*的风格,并带上完整的制品名称。但 Snapshot 提议最终去掉了所有的标识符,以方便大家使用,至少 Maven 这么做了。

对于需要处处使用标识符的地方,这就有问题了。在提交构建好的组件时,开发人员要是忘了更新版本号,而只用自动生成的数字,那就会导致 Eclipse 的仓库里会有很多主版本、小版本、补丁号都一样,只有构建标识符不同的制品。本地的 Eclipse 3.7 要升级到 3.7.2,下面的一组插件就有着相同的主版本、小版本、补丁号:

  • org.eclipse.cdt.codan.checkers.ui_1.0.0.201109151620.jar
  • org.eclipse.cdt.codan.checkers.ui_1.0.0.201202111925.jar
  • org.eclipse.core.filebuffers_3.5.200.v20110505-0800.jar
  • org.eclipse.core.filebuffers_3.5.200.v20110928-1504.jar
  • org.eclipse.core.variables_3.2.500.v20110511.jar
  • org.eclipse.core.variables_3.2.500.v20110928-1503.jar
  • org.eclipse.emf.ecore_2.7.0.v20110912-0920.jar
  • org.eclipse.emf.ecore_2.7.0.v20120127-1122.jar
  • org.eclipse.equinox.frameworkadmin.equinox_1.0.300.v20110506.jar
  • org.eclipse.equinox.frameworkadmin.equinox_1.0.300.v20110815-1438.jar
  • org.eclipse.equinox.p2.updatesite_1.0.300.v20110510.jar
  • org.eclipse.equinox.p2.updatesite_1.0.300.v20110815-1419.jar
  • org.eclipse.jdt.compiler.tool_1.0.100.v_B76_R37x.jar
  • org.eclipse.jdt.compiler.tool_1.0.100.v_B79_R37x.jar
  • org.eclipse.jface_3.7.0.I20110522-1430.jar
  • org.eclipse.jface_3.7.0.v20110928-1505.jar
  • org.eclipse.ltk.core.refactoring_3.5.201.r371_v20110824-0800.jar
  • org.eclipse.ltk.core.refactoring_3.5.201.r372_v20111101-0700.jar
  • org.eclipse.pde.runtime_3.4.201.v20110819-0851.jar
  • org.eclipse.pde.runtime_3.4.201.v20110928-1516.jar
  • org.eclipse.ui_3.7.0.I20110602-0100.jar
  • org.eclipse.ui_3.7.0.v20110928-1505.jar

问题是对那些查看文件系统或试图记住数字的人来说,这些数字通常毫无意义。如果处理制品时你用的是 P2 或 OBR(OSGi Bundle Repository)等仓库工具,那这可能并不重要;但世上的大部分构建工具还是需要用Require-Bundle来指定依赖关系的,而且需要明确的版本号和名称。这也让很多 OSGi 运行时的处理变得复杂,对已安装的 Bundle 进行比较原本是很简单的,但现在也会变得更加困难。

-SNAPSHOT/release/-SNAPSHOT模型能解决这个问题,因为版本号在推广时肯定是递增的。(这并不排除在敲定版本号之后还会有进一步的测试;但在测试阶段发现的问题通常只会改变补丁的级别。)Apache Felix 项目成功运用了这个过程,它们的发布版本都是短数字,在现有的构建系统里也很容易重用。Apache Felix 的构建要比 Equinox 容易一些,原因就是这个模型、以及这些制品在 Maven 中心库里已经是可用的了。

在 InfoQ 看来,OSGi 错失了良机。OSGi 核心平台专家组没有彻底完成方案,原因仅仅是这些相对次要的问题,所以专家组的工具化问题已经变成了人的问题。

查看英文原文:OSGi Abandons Snapshot Proposal

语言 & 开发