Pessimistic upgrade availability mapping

[evilya]

I'm trying to apply this plugin for Kotlin Multiplatform projects and getting following exception:

The exception that is the cause of unresolved state: org.gradle.internal.resolve.ModuleVersionResolveException: Could not resolve org.jetbrains.kotlinx:kotlinx-serialization-json:+.
Required by:
    project :composeApp
Caused by: org.gradle.internal.component.NoMatchingConfigurationSelectionException: No matching variant of org.jetbrains.kotlinx:kotlinx-serialization-json:1.6.3 was found. The consumer was configured to find a library for use during 'kotlin-commonized-cinterop', compatible with any Java version, as well as attribute 'org.jetbrains.kotlin.native.commonizerTarget' with value '(ios_arm64, ios_simulator_arm64, ios_x64)', attribute 'org.jetbrains.kotlin.cinteropCommonizerArtifactType' with value 'klib' but:
- Variant 'iosX64MetadataElements-published' capability org.jetbrains.kotlinx:kotlinx-serialization-json:1.6.3 declares a library:
      - Incompatible because this component declares a component for use during 'kotlin-api' and the consumer needed a component for use during 'kotlin-commonized-cinterop'
      - Other compatible attributes:
          - Doesn't say anything about its target Java version (required compatibility with any Java version)
          - Doesn't say anything about org.jetbrains.kotlin.cinteropCommonizerArtifactType (required 'klib')
          - Doesn't say anything about org.jetbrains.kotlin.native.commonizerTarget (required '(ios_arm64, ios_simulator_arm64, ios_x64)')

That's somewhat expected given how KMP libraries are published. This plugin doesn't know anything about HMPP and different targets, thus some dependencies cannot be resolved in some configurations, which is totally fine.

Debugging this plugin I found that VersionMapper.organize skips any dependency that ended up in unresolved set like this:

if (unresolved.contains(coordinate)) {
    continue
}

even if a dependency was resolved in a different configuration and actually present in latest set.
Is this sort of pessimistic upgrade resolution intentional? Or would it make sense to only skip the upgrade if a dependency wasn't resolved in all configurations?

[ben-manes]

It looks like it came in this commit. Previously, all dependencies were gathered into a single detached configuration for resolving the versions. I think that meant using gradle's RepositoryHandler to supply the detached configuration with the repositories, and that class had very buggy deduplication logic which would cause incorrect resolutions. It also meant that if a user had multiple versions of a dependency in different configurations, only one would be shown in the report. Switching to cloning configurations meant the report could be more precise. Beyond that I would guess that we didn't think about your scenario.

It has been a long time, so I don't have any thoughts or opinions here. If you think that should be changed then a PR with an explanation for why would help.