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

Hibernate使用的旧X.Y.Z.ga命名方案（请参阅this page了解新的JBoss约定）不遵循Maven的格式，可能无法与版本比较算法一起使用。引用Version number rules：

Maven核心中DefaultArtifactVersion的当前实现预计版本号将具有非常特定的格式：
<MajorVersion [> . <MinorVersion [> . <IncrementalVersion ] ] [> - <BuildNumber | Qualifier ]>
MajorVersion，MinorVersion，IncrementalVersion和BuildNumber都是数字，限定符是字符串。 如果您的版本号与此格式不符，则整个版本号将被视为限定符。

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

版本范围（遗憾的是，版本-maven-plugin无法帮助您解决版本范围和版本编号方案的问题......您可以用属性替换版本范围并使用更新 - 物业目标）

此插件中用于对版本进行排序的目标，例如update-properties（您可以帮助解决这些问题）

该算法在Dependency Mediation and Conflict Resolution中详细解释：

Default Version comparison definition

默认规范应按如下方式组成：
<major>.<minor>.<revision>([ -<qualififer> ] | [ -<build> ])
其中：


限定符部分是可选的（并且是SNAPSHOT，alpha-1，alpha-2）

构建部分是可选的（如果指定，则从1开始递增）

任何'0'构建或修订元素都可以省略。

只能给出构建和限定符中的一个（请注意，带时间戳的限定符包含内部版本号，但这不一样）

构建编号适用于重新打包原始工件的人（例如，通常使用rpms完成）


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


主要版本的数字比较

次要版本的数字比较

如果修订版不存在，请添加“.0”以进行比较

修订版的数字比较

如果限定符不存在，则比
更新
限定符的不区分大小写的字符串比较

这可确保时间戳正确排序，并且SNAPSHOT比等效时间戳更新

这也确保beta在alpha之后出现，rc
也是如此


如果没有限定符，并且构建不存在，则添加“-0”以进行比较

构建的数字比较


还请注意rpm环境中用户的建议扩展：Extending Maven 2.0 Dependencies

总结一下：

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），因此要注意意外的副作用。

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

另见

Answer 2

将存储库添加到您的pom.xml

前：

<repositories>
    <repository>
        <id>repo1</id>
        <name>repo1</name>
        <url>http://repo1.maven.org</url>
    </repository>
</repositories>

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

2 个答案:

Default Version comparison definition

另见