maven-2 - 为什么版本匹配在 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.ga Hibernate 使用的命名方案(有关新的 JBoss 约定，请参阅 this page)不遵循 Maven 的格式，并且可能不适用于版本比较算法。引用 Version number rules :

The current implementation of DefaultArtifactVersion in the core of Maven expects that version numbers will have a very specific format:

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

Where MajorVersion, MinorVersion, IncrementalVersion and BuildNumber are all numeric and Qualifier is a string. If your version number does not match this format, then the entire version number is treated as being the Qualifier.

If your version numbers do not match this scheme, you may face issues with

• version ranges (unfortunately there is nothing that the versions-maven-plugin can do to help you with your problems with version ranges and your version numbering scheme... well you could replace your version ranges with properties and use the update-properties goal)
• goals in this plugin that sort versions, for example update-properties (you can do things to help with these kinds of problems)

算法在 Dependency Mediation and Conflict Resolution中有详细解释:

Default Version comparison definition

The default specification should be composed as follows:

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

where:

• the qualifier section is optional (and is SNAPSHOT, alpha-1, alpha-2)
• the build section is optional (and increments starting at 1 if specified)
• any '0' build or revision elements can be omitted.
• only one of build and qualifier can be given (note that the timestamped qualifier includes a build number, but this is not the same)
• the build number is for those that repackage the original artifact (eg, as is often done with rpms)

For ordering, the following is done in order until an element is found that are not equal:

• numerical comparison of major version
• numerical comparison of minor version
• if revision does not exist, add ".0" for comparison purposes
• numerical comparison of revision
• if qualifier does not exist, it is newer than if it does
• case-insensitive string comparison of qualifier
  • this ensures timestamps are correctly ordered, and SNAPSHOT is newer than an equivalent timestamp
  • this also ensures that beta comes after alpha, as does rc
• if no qualifier, and build does not exist, add "-0" for comparison purposes
• numerical comparison of build

Note also the proposed extension from a user in an rpm environment: 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)，因此请注意意外的副作用。

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

也可以看看

Dependency Version Ranges

Improve default support for version schemes