[
https://issues.apache.org/jira/browse/MNG-7559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614243#comment-17614243
]
Andrzej Jarmoniuk edited comment on MNG-7559 at 10/7/22 8:17 PM:
-----------------------------------------------------------------
So, the least intrusive "fix" (if I may, but I'm not really sure if the
"business" logic is correct here) is simply inverting the condition here:
{code:java}
/**
* Returns a comparable for a qualifier.
* <p/>
* This method both takes into account the ordering of known qualifiers
as well as lexical ordering for unknown
* qualifiers.
* <p/>
* just returning an Integer with the index here is faster, but
requires a lot of if/then/else to check for -1
* or QUALIFIERS.size and then resort to lexical ordering. Most
comparisons are decided by the first character,
* so this is still fast. If more characters are needed then it
requires a lexical sort anyway.
*
* @param qualifier
* @return
*/
public static Comparable comparableQualifier( String qualifier )
{
int i = QUALIFIERS_LIST.indexOf( qualifier );
return i == -1 ? "0-" + qualifier : String.valueOf( i );
}
{code}
which makes unknown qualifiers compare as less major than releases, just like
most known qualifiers.
It looks like this inversion will not trigger any errors in integration tests
in versions-maven-plugin (which is understandable considering the fact that
non-standard qualifiers are not common), but the question remains: what should
the actual behaviour be here? And I think this behaviour must also be in line
across the board, i.e. at least between versions-maven-plugin and maven itself.
was (Author: ajarmoniuk):
So, the least intrusive "fix" (if I may, but I'm not really sure if the
"business" logic is correct here) is simply inverting the condition here:
{code:java}
/**
* Returns a comparable for a qualifier.
* <p/>
* This method both takes into account the ordering of known qualifiers
as well as lexical ordering for unknown
* qualifiers.
* <p/>
* just returning an Integer with the index here is faster, but
requires a lot of if/then/else to check for -1
* or QUALIFIERS.size and then resort to lexical ordering. Most
comparisons are decided by the first character,
* so this is still fast. If more characters are needed then it
requires a lexical sort anyway.
*
* @param qualifier
* @return
*/
public static Comparable comparableQualifier( String qualifier )
{
int i = QUALIFIERS_LIST.indexOf( qualifier );
return i == -1 ? "0-" + qualifier : String.valueOf( i );
}
{code}
which makes unknown qualifiers compare as less major than releases, just like
most known qualifiers.
> ComparableVersion vs versions with custom qualifiers
> ----------------------------------------------------
>
> Key: MNG-7559
> URL: https://issues.apache.org/jira/browse/MNG-7559
> Project: Maven
> Issue Type: Bug
> Affects Versions: 3.8.3
> Reporter: Andrzej Jarmoniuk
> Priority: Major
>
> Since I know that ComparableVersion was brought to Maven from
> versions-maven-plugin, it turns out the bug described here:
> https://github.com/mojohaus/versions-maven-plugin/issues/744
> also exists in maven, at least in 3.8.3.
> According to the maven version spec, versions containing a qualifier should
> be treated as less major than the same versions without the qualifier.
> Currently it's only the case for a few "standard" qualifiers, e.g. "-rc*",
> "-alpha", etc.
> However, it looks like "2.3-pfd" is deemed less major than "2.3".
> {code:java}
> @Test
> public void testComparableVersionWithCustomQualifier()
> {
> assertThat( new ComparableVersion( "2.3" ).compareTo( new
> ComparableVersion( "2.3-pfd" ) ),
> greaterThan( 0 ) );
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
