Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Not A Problem
-
3.0.4
-
None
-
None
-
Linux 64-bit
Description
When using a version range, e.g. "[1.0-SNAPSHOT,)", versions with more than four components are not sorted correctly. For example, "1.0.0.0" will be sorted as greater/later than "1.0.0.0.0". However, "1.0.0" will be sorted as greater/later than "1.0.0.0".
The behavior here is a bit odd... all of the maven-metadata-XXX.xml files in the local repository will correctly list "1.0.0.0.0" as the "latest" and "release" version, but running compile, dependency:tree, etc. will instead select "1.0.0.0". Aether API calls are also exhibiting the buggy sorting behavior, too.
I haven't yet tried any debugging to track this down, but I've trolled through git and my best guess is that this behavior is related to the version of maven-artifact being used. The 2.x releases DefaultArtifactVersion.compareTo(...) method does not correctly handle versions with more than four components, but the 3.x releases of it do [1]. Maybe the problem is just that the compile plugin is still using maven-artifact:2.0.9?
This is hurting us here. While many of our projects use versions with four or less components, we follow the add a version component for branches versioning strategy to prevent version conflicts between branches. This allows us to use version ranges in our POMs, making life a lot easier.
[1] The following commit seems to be where this was fixed in maven-artifact: maven.git beb9d731691beed1b0099a790a8ae1973f55dc0b. It looks like the code is what was originally proposed in the Improve default support for version schemes Maven wiki page.