本文主要是介绍OSGi放弃了Snapshot提议，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
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-456 比1.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
译者 王丽娟 王丽娟，04年大学毕业后持续从事Java EE中间件产品的开发，现在主要关注Java技术及中间件产品在云计算环境中的发展趋势和应用。
这篇关于OSGi放弃了Snapshot提议的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
