Version matching is inverted in SelectJdkToolchainMojo.matches() for VERSION key

[elharo]

Summary

The matches(String key, String reqVal, String tcVal) method in SelectJdkToolchainMojo passes arguments in the wrong order to RequirementMatcherFactory.createVersionMatcher(). This means version constraints specified via -Dtoolchain.jdk.version=... will not produce correct matching.

Location

SelectJdkToolchainMojo.java:187-191

https://github.com/apache/maven-toolchains-plugin/blob/master/src/main/java/org/apache/maven/plugins/toolchain/jdk/SelectJdkToolchainMojo.java#L187-L191

Code

private boolean matches(String key, String reqVal, String tcVal) {
    switch (key) {
        case VERSION:
            return RequirementMatcherFactory.createVersionMatcher(tcVal).matches(reqVal);
        ...
    }
}

Here tcVal is the toolchain's version value and reqVal is the user's requirement (e.g., "[11,17)").

Problem

The standard Maven Toolchain API pattern (as used internally by DefaultToolchain.matchesRequirements()) is:

1. Create a version range matcher from the requirement value
2. Check if the toolchain's provides value is within that range

This code does the opposite: it creates a version range from the toolchain's concrete version (which is a specific value, not a range) and checks if the requirement string is within it. The semantics are inverted.

For example, with a toolchain version "11.0.1" and a requirement "[11,17)":

• Expected: "11.0.1" is within range "[11,17)" -> match
• Actual: creates range "11.0.1" (which is just the single version 11.0.1) and checks if "[11,17)" is within 11.0.1 -> likely no match

Impact

The select-jdk-toolchain goal's -Dtoolchain.jdk.version parameter will not correctly match JDK toolchains. Users specifying version ranges will get unexpected "Cannot find matching toolchain" failures.

Suggested Fix

Swap the arguments:

return RequirementMatcherFactory.createVersionMatcher(reqVal).matches(tcVal);