Candidate set provided to AttributeDisambiguationRule contains null entry
#6747
Comments
|
Adding info for users which are not from Google corp: https://issuetracker.google.com/issues/112231683 because they can't use link on #6747 (comment) Link to repo: https://github.com/mtrakal/issue112231683 which allow reproduce this bug |
|
Thanks for reporting this issue. I've done some debugging, and the fundamental issue is caused by the fact that MultipleCandidateDetails.getCandidateValues() can currently contain a null value, if any of the variants are missing this attribute. AnalysisApplying the Note that this is further complicated by the fact that our exception reporting also barfs on the SolutionI'm attempting to find a fix that eliminates the null value from the candidate set, but this is proving elusive so far. If I manage to find a relatively simple fix I'll try to get it into the upcoming In the meantime, you should be able to update |
bigdaz
changed the title
AttributeDisambiguationRule contains null entry
|
@jdochez We've implemented a fix which will be in the upcoming You can grab a pre-release distro from http://services.gradle.org/distributions-snapshots/gradle-4.10.2-20180917175211+0000-all.zip |
|
@mtrakal Please try out the above nightly that contains a fix for this issue. ☝️ |
|
@bigdaz We had this issue in our project as well and I can confirm that the pre-release distro works for us 👍 |
|
@bigdaz I can confirm that's working like a charm too :). Thanks a lot for the fix 👍 🥇 |
|
Awesome, works for me too with the 4.10.2 nightly :) I can finally remove the useless buildType in all my libraries modules which was a temporary hack in order to have all the same buildType in all modules! |
|
IMO the fix for this issue somewhat introduces a conceptual flaw into attributes disambiguation process: there is no more a way to disambiguate an absent attribute ( In the code of the We add a special attribute Prior to 4.10.2, this worked fine. In 4.10.2+, ambiguity arises due to the |
|
Thanks for the insight @h0tk3y .
I think this is the problem, it should have been setup the other way around: attributes are used to select a configuration, not to exclude them. So preferring So one option is just to add the attribute to every configuration, and set a value like |
In Gradle 4.10.2, a change was made in the attributes disambiguation process: some if the candidates have a single attribute value and others don't have that attribute (i.e. have a null value), the disambiguation rule for that attribute doesn't get called. Effectively, null values are excluded from disambiguation, but still may cause ambiguity (sic!) See: gradle/gradle#6747 (comment) This change affected our attribute `localToProject` that we use to disambiguate the deprecated but still consumable configurations like `compile`, `runtime`, `testCompile`, `testRuntime` from those configurations which should have priority during project dependency resolution: the `*Element` ones. Our scheme marked the former configurations with the attribute and the latter were not marked, with a disambiguation rule that preferred null values. To fix this logic with Gradle 4.10.2, we instead mark both kinds of configurations with the attribute, which now has a value 'public' that is preferred by the rule over the other values. We also make sure that the attribute doesn't leak into the published Gradle metadata, as it is only needed for project-to-project dependencies resolution.
In Gradle 4.10.2, a change was made in the attributes disambiguation process: some if the candidates have a single attribute value and others don't have that attribute (i.e. have a null value), the disambiguation rule for that attribute doesn't get called. Effectively, null values are excluded from disambiguation, but still may cause ambiguity (sic!) See: gradle/gradle#6747 (comment) This change affected our attribute `localToProject` that we use to disambiguate the deprecated but still consumable configurations like `compile`, `runtime`, `testCompile`, `testRuntime` from those configurations which should have priority during project dependency resolution: the `*Element` ones. Our scheme marked the former configurations with the attribute and the latter were not marked, with a disambiguation rule that preferred null values. To fix this logic with Gradle 4.10.2, we instead mark both kinds of configurations with the attribute, which now has a value 'public' that is preferred by the rule over the other values. We also make sure that the attribute doesn't leak into the published Gradle metadata, as it is only needed for project-to-project dependencies resolution.
In Gradle 4.10.2, a change was made in the attributes disambiguation process: if some of the candidates have a single attribute value and others don't have that attribute (i.e. have a null value), the disambiguation rule for that attribute doesn't get called. Effectively, null values are excluded from disambiguation, but still may cause ambiguity (sic!) See: gradle/gradle#6747 (comment) This change affected our attribute `localToProject` that we use to disambiguate the deprecated but still consumable configurations like `compile`, `runtime`, `testCompile`, `testRuntime` from those configurations which should have priority during project dependency resolution: the `*Element` ones. Our scheme marked the former configurations with the attribute and the latter were not marked, with a disambiguation rule that preferred null values. To fix this logic with Gradle 4.10.2, we instead mark both kinds of configurations with the attribute, which now has a value 'public' that is preferred by the rule over the other values. We also make sure that the attribute doesn't leak into the published Gradle metadata, as it is only needed for project-to-project dependencies resolution. Issue #KT-28795 Fixed
In Gradle 4.10.2, a change was made in the attributes disambiguation process: if some of the candidates have a single attribute value and others don't have that attribute (i.e. have a null value), the disambiguation rule for that attribute doesn't get called. Effectively, null values are excluded from disambiguation, but still may cause ambiguity (sic!) See: gradle/gradle#6747 (comment) This change affected our attribute `localToProject` that we use to disambiguate the deprecated but still consumable configurations like `compile`, `runtime`, `testCompile`, `testRuntime` from those configurations which should have priority during project dependency resolution: the `*Element` ones. Our scheme marked the former configurations with the attribute and the latter were not marked, with a disambiguation rule that preferred null values. To fix this logic with Gradle 4.10.2, we instead mark both kinds of configurations with the attribute, which now has a value 'public' that is preferred by the rule over the other values. We also make sure that the attribute doesn't leak into the published Gradle metadata, as it is only needed for project-to-project dependencies resolution. Issue #KT-28795 Fixed
In Gradle 4.10.2, a change was made in the attributes disambiguation process: if some of the candidates have a single attribute value and others don't have that attribute (i.e. have a null value), the disambiguation rule for that attribute doesn't get called. Effectively, null values are excluded from disambiguation, but still may cause ambiguity (sic!) See: gradle/gradle#6747 (comment) This change affected our attribute `localToProject` that we use to disambiguate the deprecated but still consumable configurations like `compile`, `runtime`, `testCompile`, `testRuntime` from those configurations which should have priority during project dependency resolution: the `*Element` ones. Our scheme marked the former configurations with the attribute and the latter were not marked, with a disambiguation rule that preferred null values. To fix this logic with Gradle 4.10.2, we instead mark both kinds of configurations with the attribute, which now has a value 'public' that is preferred by the rule over the other values. We also make sure that the attribute doesn't leak into the published Gradle metadata, as it is only needed for project-to-project dependencies resolution. Issue #KT-28795 Fixed
In Gradle 4.10.2, a change was made in the attributes disambiguation process: if some of the candidates have a single attribute value and others don't have that attribute (i.e. have a null value), the disambiguation rule for that attribute doesn't get called. Effectively, null values are excluded from disambiguation, but still may cause ambiguity (sic!) See: gradle/gradle#6747 (comment) This change affected our attribute `localToProject` that we use to disambiguate the deprecated but still consumable configurations like `compile`, `runtime`, `testCompile`, `testRuntime` from those configurations which should have priority during project dependency resolution: the `*Element` ones. Our scheme marked the former configurations with the attribute and the latter were not marked, with a disambiguation rule that preferred null values. To fix this logic with Gradle 4.10.2, we instead mark both kinds of configurations with the attribute, which now has a value 'public' that is preferred by the rule over the other values. We also make sure that the attribute doesn't leak into the published Gradle metadata, as it is only needed for project-to-project dependencies resolution. Issue #KT-28795 Fixed (cherry picked from commit 557fb07)
In Gradle 4.10.2, a change was made in the attributes disambiguation process: if some of the candidates have a single attribute value and others don't have that attribute (i.e. have a null value), the disambiguation rule for that attribute doesn't get called. Effectively, null values are excluded from disambiguation, but still may cause ambiguity (sic!) See: gradle/gradle#6747 (comment) This change affected our attribute `localToProject` that we use to disambiguate the deprecated but still consumable configurations like `compile`, `runtime`, `testCompile`, `testRuntime` from those configurations which should have priority during project dependency resolution: the `*Element` ones. Our scheme marked the former configurations with the attribute and the latter were not marked, with a disambiguation rule that preferred null values. To fix this logic with Gradle 4.10.2, we instead mark both kinds of configurations with the attribute, which now has a value 'public' that is preferred by the rule over the other values. We also make sure that the attribute doesn't leak into the published Gradle metadata, as it is only needed for project-to-project dependencies resolution. Issue #KT-28795 Fixed
This commit implements a smarter strategy for attribute disambiguation, whenever _some_ variants have missing information. By missing information, we mean that some variants carry at least one extra attribute, and others do not. Because we consider the absence of an attribute as a compatible match, BUT that when we disambiguate we only consider the variants which actually provided a value, there was no way to prefer a match which is "closer" to the request. See #6747
This commit implements a smarter strategy for attribute disambiguation, whenever _some_ variants have missing information. By missing information, we mean that some variants carry at least one extra attribute, and others do not. Because we consider the absence of an attribute as a compatible match, BUT that when we disambiguate we only consider the variants which actually provided a value, there was no way to prefer a match which is "closer" to the request. See #6747
This is a mirror bug for :
https://issuetracker.google.com/issues/112231683
if you check out the small example project, you will be able to reproduce the NPE by changing
libx/build.gradle
// releaseDebug {
// }
basically removing the build type on the library forces the resolution strategy to kick in in the app module.
when android-kotlin plugin is disabled, it works. When it is enabled, NPE during configuration.
I have checked that we set up the AttributeMatchingStrategy correctly independently of the kotlin plugin presence so it does not seem to be an android gradle plugin issue.
The text was updated successfully, but these errors were encountered: