Geek Answers Handbook

Why doesn't version compatibility work in Maven?

This is my pom.xml (fragment of it):

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

Here is what mvn says:

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

Why?

+6
maven-2
source share
2 answers

The old XYZga naming scheme used by Hibernate (see this page for new JBoss conventions) does not match the Maven format and may not work well with the version comparison algorithm. Citation Version Number Rules :

The current implementation of DefaultArtifactVersion in the Maven kernel expects version numbers to have a very specific format:

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

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

If your version numbers do not fit this pattern, you may run into problems using

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

The algorithm is explained in detail in Dependency Mediation and Conflict Resolution :

Defining default version comparison

The standard specification should be as follows:

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

Where:

  • qualifier section is optional (and is SNAPSHOT, alpha-1, alpha-2)
  • assembly section is optional (and increases in increments of 1, if specified)
  • Assembly or revision "0" elements may be omitted.
  • only one of the collectors and qualifiers can be specified (note that the timestamped qualifier contains the assembly number, but this is not the same)
  • build number is for those who repackage the original artifact (for example, as is often done with rpms)

To organize, the following is performed until an element is found that is not equal:

  • numerical comparison of the main version
  • numerical comparison of the younger version
  • If the revision does not exist, add ".0" for comparison purposes.
  • numerical version comparison
  • if the qualifier does not exist, it is newer than if it does
  • case insensitive string comparison
    • this ensures that the timestamps are correctly ordered, and SNAPSHOT is newer than the equivalent timestamp
    • it also ensures that beta comes after alpha, like rc
  • if the qualifier does not exist, and the assembly does not exist, add "-0" for comparison purposes.
  • assembly numerical comparison

Check out the suggested user extension in rpm: Maven 2.0 Dependency Extension

Summarizing:

  • 3.2.0.cr2, 3.2.0.ga, 3.3.1.ga are considered as a determinant (i.e. 0.0.0-3.2.0.cr2, etc. somehow become)
  • Knowing this, you can probably trick Maven into using the range [0.0.0-3.0,) .
  • But this will correspond to more versions than we would like (for example, 2.x), so be careful with unexpected side effects.

Actually, my recommendation is not to use version ranges at all, they are just bad for reproducible builds.

see also

+10
source share

Add repository to your pom.xml

Example:

 <repositories> <repository> <id>repo1</id> <name>repo1</name> <url>http://repo1.maven.org</url> </repository> </repositories>
-4
source share

More articles:


All Articles