[MRESOLVER-686] Exception: Comparison method violates its general contract

[jira-importer]

Ralf Naujokat opened MRESOLVER-686 and commented

I got this exception when using the versions-maven-plugin
while scanning for dependency updates.
it looks like the error doesn't come from the plugin but from some internal maven component.
many details are already discussed here:
mojohaus/versions#1147

 

---

No further details from MRESOLVER-686

[jira-importer]

Michael Osipov commented

Tamas Cservenak

[jira-importer]

Tamas Cservenak commented

Refd issue contains two kind of "unorthodox" version numbers:

• '-SNAPSHOT' versions + AF
• with hex versions

Unsure what the problem was in first case, but in second according to version spec as docd here https://github.com/apache/maven-resolver/blob/81e5a0ed635081c8797e02f394a836a3027b33b0/maven-resolver-util/src/main/java/org/eclipse/aether/util/version/package-info.java this result in a potentially long "segments" (as each transition from number to letter and other way around denotes a segment boundary, see "implicit delimiters". In short, Maven does not handle versions as "opaque strings" (it cannot, as it has to define ordering), but hex versions is not something it can use, at least not without some "orthodox" (read: sane) prefix like "1.0.0-deadbeef" or alike.

A workaround could be to use same (static, unchanging) prefix like "1.0.0-" and append the hex, and the issue would be gone.

[elharo]

The compareTo method in GenericVersion should not violate the general contract of the method. If it does, and if it's a requirement of Maven version ordering — i.e. if Maven version ordering is somehow incompatible with compareTo — then we shouldn't be using Comparable for sorting maven versions.