[
https://jira.codehaus.org/browse/MNG-5777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=364327#comment-364327
]
Sergei Ivanov commented on MNG-5777:
------------------------------------
I agree that not all requirements are comparable. Perhaps value comparator
should be an optional feature of a {{RequirementsMatcher}}, perhaps installed
there by toolchain factory. That would allow to compare certain requirements,
such as {{version}}, where a natural comparison exists. Where there's no
obvious order, such as for {{vendor}}, no comparator will be provided.
If there was a priority ordering between the requirements, that would allow to
resolve some of the conflicts. E.g. if both {{vendor}} and {{version}} were
specified, then the toolchains would first be matched on {{vendor}} and only
then on {{version}} for the specified {{vendor}}.
I agree, this does not solve the problem completely and still leaves the room
for conflicting matches in some configurations. In such cases I think your
proposed system property based approach would be a pretty good solution for
controlling the build externally. That means, Maven should probably abort the
build if an ambiguous toolchain match exists, and then the user would either be
forced to fix the POM config or provide a system property on the command line.
> 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.
> @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.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
