gradle-versions-plugin: Unable to resolve latest versions for Kotlin MPP projects

@Vampire The variant metadata issue in your project is solved #438. Hopefully we’re now fully MPP compatible.

Thanks! Its past midnight my time, so I’ll look into cleaning up the code snippets and making the changes sometime this week.

Ideally recent plugins should flag configurations according to their role using the canBeResolved and canBeConsumed properties. However if you were to resolve a configuration that says canBeResolved = false it would fail.

And indeed, this plugin changes all configuration to be canBeResolved = true - done following #127.

So for example in the context of the java plugin, you should never resolve compileOnly, runtimeOnly, implementation but instead compileClasspath and runtimeClasspath. There will still be a minor issue with legacy configurations like compile and runtime which ideally should not be resolved (and will warn about it in upcoming Gradle 6.0).

From looking at the plugin documentation, I do not see a place where the specific configuration resolved matters in the output report. But I do not know the plugin well enough to be confident.

So maybe that state change on copied configurations can be removed while preserving functionality.

Thx, works much better now for those 😃

I have a fix in #421 which resolves the issue in @ZacSweers’ project. For other users, I didn’t see public repositories to test against. For confirmation, can you please try out this build against your project or, if public, let me know the repository to test against? I believe @Vampire @mike-ross-88 had projects showing this problem.

@ben-manes I’m sorry you found my message disrespectful. My intent is definitely to help, heck, that’s why I worked on a solution while also trying solve other problems that this project doesn’t aim at solving.

I’m seeking to help folks/projects that are affected this issue (some for almost a year or more).

Do you think it’s not helpful? If so, you can ask me to remove my comment and I’ll kindly do it.

Regarding this plugin:

I know that it is using version ranges (+) to get the latest release through Gradle configuration resolving, and puts them all in a single configuration, while some dependencies cannot live in the same configuration since gradle metadata.

While working on refreshVersions, I’ve tried the same as this plugin at first, and to workaround that issue with dependencies that cannot be in the same configuration, I was creating a configuration with the + version, resolving it to get the latest version, and I destroyed it, and so on, for every dependency. It was quite slow, but I believe you could get it faster by simply copying all the configurations to a derived one, and resolve all the configurations independently so their dependencies don’t clash (unless the users misconfigured it, but that’d fail the regular build too). I eventually used another approach, making a trade-off (retrieving the maven-metadata.xml files directly, which works only with non authenticated repos or basic credentials repos for now, while configuration resolving can work for everything), but I think that multi-configuration approach could work for this plugin.

For people struggling there, @jmfayard and I made a plugin named refreshVersions that works with Kotlin Multiplatform projects, is faster (because dependencies versions retrieval happens in parallel), and also helps applying the updates quickly.

You can take a look at the documentation here: https://github.com/jmfayard/refreshVersions

Feel free to give it a try!

This is because you use force in your resolution strategy for all configurations (see #265 for workarounds)

@LouisCAD While offering assistance and even suggesting alternatives as temporary workarounds is appreciated, evangelizing on other projects without intent to help is disrespectful. Please refrain if you are unwilling to offer actual help.

Yes, they seem to be the same. We’ll need to try @ljacomet suggestion of removing canBeResolved override for Gradle 6+ users to instead skip those configurations. Hopefully that resolves things, now that 6.0 has deprecated them so it should be safer to drop that hack. I haven’t tried it yet, but am hopeful.

As commented in gradle/gradle#6389, the issues are on a similar topic but here it looks like a consumer problem and not a producer one.

In a comment above (too long to quote), what stands out is that there are effectively 0 consumer attributes on the dependency being resolved. The extract indicates the faulty project, app, but not the configuration itself.

Anyway, without requested attributes and with multiple candidate variants, disambiguation rules should be triggered.

Gradle has a default rule for JVM projects which should prefer java-runtime. Kotlin plugins define their own rule which should also pick java-runtime when nothing is requested. Unfortunately, there is another Kotlin added attribute, org.jetbrains.kotlin.platform.type, which also has a disambiguation rule. But that one prefers common when no value is requested. This means that between java-runtime and common as disambiguated values, there is no matching variant.

Doing a bit of debugging in the test project, I notice that there are multiple attempts to resolve configurations like debugImplementationCopy but these have effectively no attributes.

I am not familiar with the internals of this plugin, but clearly configurations like debugImplementation are not made to be resolved independently.