[
https://jira.codehaus.org/browse/MNG-5777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-5777:
--------------------------------
Description:
If multiple toolchains of the same type match the requested version range, then
the first toolchain in {{toolchains.xml}} is selected. This is because the
first matching toolchain wins unconditionally, and there is no way nor means to
resolve ties. Please see the attached example.
{noformat}
mvn validate -t toolchains1.xml
[INFO] --- maven-toolchains-plugin:1.1:toolchain (default-toolchain) @
toolchains-test ---
[INFO] Required toolchain: jdk [ version='[1.7,)' ]
[INFO] Found matching toolchain for type jdk: JDK[C:/Java/jdk1.8.0_31_x64]
mvn validate -t toolchains2.xml
[INFO] --- maven-toolchains-plugin:1.1:toolchain (default-toolchain) @
toolchains-test ---
[INFO] Required toolchain: jdk [ version='[1.7,)' ]
[INFO] Found matching toolchain for type jdk: JDK[C:/Java/jdk1.7.0_76_x64]
{noformat}
I think that a {{RequirementsMatcher}} may need two additional features:
# order (or priority), so that e.g. a match against 'id' key takes precedence
over a match against 'vendor' key. This is specific to the toolchain type and
can be provided by toolchain factory at the time of reading the toolchain
definition.
# comparison for the matched values with the same key, so that e.g. two
versions matching the same version range can be compared. We may need some sort
of hinting or pluggable strategy here, so that e.g. either the lowest version
in the range is preferred, or the highest.
Then instead of picking the first matching toolchain, Maven would collect all
matching toolchains, and then sift through them using the comparison criteria
above. If that still results in a tie, then it would either abort the
execution, or pick the first toolchain and proceed with it.
@[~rfscholte]: I saw you've made a lot of changes in the area recently, and
maybe you have already considered possible solutions for this particular
problem.
was:
If multiple toolchains of the same type match the requested version range, then
the first toolchain in {{toolchains.xml}} is selected. This is because the
first matching toolchain wins unconditionally, and there is no way nor means to
resolve ties. Please see the attached example.
{noformat}
mvn validate -t toolchains1.xml
[INFO] --- maven-toolchains-plugin:1.1:toolchain (default-toolchain) @
toolchains-test ---
[INFO] Required toolchain: jdk [ version='[1.7,)' ]
[INFO] Found matching toolchain for type jdk: JDK[C:/Java/jdk1.8.0_31_x64]
mvn validate -t toolchains2.xml
[INFO] --- maven-toolchains-plugin:1.1:toolchain (default-toolchain) @
toolchains-test ---
[INFO] Required toolchain: jdk [ version='[1.7,)' ]
[INFO] Found matching toolchain for type jdk: JDK[C:/Java/jdk1.7.0_76_x64]
{noformat}
I think that a {{RequirementsMatcher}} may need two additional features:
# order (or priority), so that e.g. a match against 'id' key takes precedence
over a match against 'vendor' key. This is specific to the toolchain type and
can be provided by toolchain factory at the time of reading the toolchain
definition.
# comparison for the matched values with the same key, so that e.g. two
versions matching the same version range can be compared. We may need some sort
of hinting or pluggable strategy here, so that e.g. either the lowest version
in the range is preferred, or the highest.
Then instead of picking the first matching toolchain, Maven would collect all
matching toolchains, and then sift through them using the comparison criteria
above. If that still results in a tie, then it would either abort the
execution, or pick the first toolchain and proceed with it.
@Robert Scholte: I saw you've made a lot of changes in the area recently, and
maybe you have already considered possible solutions for this particular
problem.
> Matching of toolchains against version ranges depends on their order of
> declaration
> -----------------------------------------------------------------------------------
>
> Key: MNG-5777
> URL: https://jira.codehaus.org/browse/MNG-5777
> Project: Maven
> Issue Type: Bug
> Components: Toolchains
> Affects Versions: 3.2.5
> Environment: Apache Maven 3.2.5
> (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T17:29:23+00:00)
> Java version: 1.8.0_31, vendor: Oracle Corporation
> Default locale: en_GB, platform encoding: Cp1251
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
> Reporter: Sergei Ivanov
> Attachments: toolchains-test.zip
>
>
> If multiple toolchains of the same type match the requested version range,
> then the first toolchain in {{toolchains.xml}} is selected. This is because
> the first matching toolchain wins unconditionally, and there is no way nor
> means to resolve ties. Please see the attached example.
> {noformat}
> mvn validate -t toolchains1.xml
> [INFO] --- maven-toolchains-plugin:1.1:toolchain (default-toolchain) @
> toolchains-test ---
> [INFO] Required toolchain: jdk [ version='[1.7,)' ]
> [INFO] Found matching toolchain for type jdk: JDK[C:/Java/jdk1.8.0_31_x64]
> mvn validate -t toolchains2.xml
> [INFO] --- maven-toolchains-plugin:1.1:toolchain (default-toolchain) @
> toolchains-test ---
> [INFO] Required toolchain: jdk [ version='[1.7,)' ]
> [INFO] Found matching toolchain for type jdk: JDK[C:/Java/jdk1.7.0_76_x64]
> {noformat}
> I think that a {{RequirementsMatcher}} may need two additional features:
> # order (or priority), so that e.g. a match against 'id' key takes precedence
> over a match against 'vendor' key. This is specific to the toolchain type and
> can be provided by toolchain factory at the time of reading the toolchain
> definition.
> # comparison for the matched values with the same key, so that e.g. two
> versions matching the same version range can be compared. We may need some
> sort of hinting or pluggable strategy here, so that e.g. either the lowest
> version in the range is preferred, or the highest.
> Then instead of picking the first matching toolchain, Maven would collect all
> matching toolchains, and then sift through them using the comparison criteria
> above. If that still results in a tie, then it would either abort the
> execution, or pick the first toolchain and proceed with it.
> @[~rfscholte]: I saw you've made a lot of changes in the area recently, and
> maybe you have already considered possible solutions for this particular
> problem.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
