为什么版本匹配在Maven中不起作用？

Question

这是我的pom.xml(片段):

...
<dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-entitymanager</artifactId>
    <version>[3.0,)</version>
</dependency>
...

这就是mvn告诉我的:

Couldn't find a version in [3.2.0.cr2, 3.2.0.ga, 3.3.1.ga] to match range [3.0,)

为什么？

Answer 1

X.Y.Z.gaHibernate使用的旧命名方案(请参阅此页面了解新的JBoss约定)不遵循Maven的格式,并且可能无法与版本比较算法一起使用.引用版本号规则:

DefaultArtifactVersionMaven核心的当前实现预计版本号将具有非常特定的格式:

<MajorVersion [> . <MinorVersion [> . <IncrementalVersion ] ] [> - <BuildNumber | Qualifier ]>

其中MajorVersion,MinorVersion,IncrementalVersion和BuildNumber都是数字和限定符是一个字符串.如果您的版本号与此格式不匹配,则整个版本号将被视为限定符.

如果您的版本号与此方案不匹配,则可能会遇到问题

• 版本范围(遗憾的是,版本-maven-plugin无法帮助您解决版本范围和版本编号方案的问题......您可以用属性替换版本范围并使用update-properties目标)
• 这个插件中的目标是对版本进行排序,例如update-properties(你可以做些事来帮助解决这些问题)

在依赖性调解和冲突解决中详细解释了该算法:

默认版本比较定义

默认规范应如下组成:

<major>.<minor>.<revision>([ -<qualififer> ] | [ -<build> ])

哪里:

• 限定符部分是可选的(并且是SNAPSHOT,alpha-1,alpha-2)
• 构建部分是可选的(如果指定,则从1开始递增)
• 任何'0'构建或修订元素都可以省略.
• 只能给出构建和限定符中的一个(请注意,带时间戳的限定符包含内部版本号,但这不相同)
• 构建编号适用于重新打包原始工件的人(例如,通常使用rpms)

对于排序,按顺序完成以下操作,直到找到不相等的元素:

• 主要版本的数字比较
• 次要版本的数字比较
• 如果修订版不存在,请添加".0"以进行比较
• 修订的数字比较
• 如果限定符不存在,则它比它更新
• 不区分大小写的字符串比较限定符
  • 这可确保正确排序时间戳,并且SNAPSHOT比等效时间戳更新
  • 这也确保beta在alpha之后出现,rc也是如此
• 如果没有限定符,并且构建不存在,则添加"-0"以进行比较
• 构建的数字比较

还要注意rpm环境中用户的建议扩展:扩展Maven 2.0依赖项

总结一下:

• 3.2.0.cr2,3.2.0.ga,3.3.1.ga被视为限定符(即它们以某种方式变为0.0.0-3.2.0.cr2等)
• 知道了这一点,你可以使用[0.0.0-3.0,)范围来欺骗Maven .
• 但是这将匹配比想要的更多版本(例如2.x),因此要注意意外的副作用.

实际上,我的建议是根本不使用版本范围,它们只对可重现的版本不利.

也可以看看

• 依赖版本范围
• 改进版本方案的默认支持