Investigate if the plugin should (or could) do its own dependency resolving

[hvisser]

This plugin relies on the Gradle versions plugin, which solves the difficult task of figuring out the actual dependency updates that need to go into the TOML file. There are some issues with this plugin that seem to manifest multiple times:

• It works on the dependencies that are actually used. This is useful for removing unused dependencies, but it poses a problem when dependencies cannot be detected, such as buildSrc dependencies. When libraries are declared in the TOML file that aren't actually used, they won't be upgraded either for that reason. Technically this is all correct, but it can be confusing.
• Sometimes it is not clear why dependencies are not upgraded. This could be a Gradle issue, freshness of repositories or an issue in the versions plugin, but this is also hard to explain or debug.
• There are issues with multi module projects, due to stricter checks in Gradle.

Resolving dependencies within the Version Catalog Updates plugin

At first sight a minimal way to resolve the versions could be to build a configuration for the entire TOML file(s) and resolve that. This has the benefit of treating the TOML file as the absolute source of truth + there's no need to rely on resolving dependencies from the actual modules.

The downside is that detecting "unused" dependencies is no longer possible, but IDE tooling is getting better and highlighting this so this might not be a huge issue.

The risk is that there are a bunch of edge cases that are unknown (to me) which the versions plugin might have already solved. OTOH since we only have the info from the TOML file, there might be less guessing and less edge cases.

[emartynov]

As for me, decoupling and focusing on the primary purpose of this plugin is a good step. There are also first-purpose plugins for finding unused deps, etc., such as the deps analysis gradle plugin.

[jamesward]

This would enable me to use this plugin for https://github.com/jamesward/kotlin-universe-catalog as it just has reusable catalogs but doesn't actually use the dependencies in those catalogs.

BTW: Thanks for this plugin!

[hvisser]

@jamesward That sounds like a great use case! I'm I think I'm almost ready to wrap up the PR, would be awesome if you can try out the snapshot or the release when that's out.

[jamesward]

I'd love to test it out!

[hvisser]

I've merged the PR, the current 0.8.2-SNAPSHOT has these changes and I'll do a release soon.

[jamesward]

Thanks! I'm trying it here: https://github.com/jamesward/kotlin-universe-catalog/tree/version-catalog-update

Getting an error:

   > There was an error while evaluating a component selection rule for com.apollographql.apollo3:apollo-api-jvm:3.8.2.
      > Required value was null.

Also, I can't figure out how to set the versionSelector differently for different catalogs. Maybe that config needs to be available on VersionCatalogConfig ?

Really appreciate all your work on this!

[hvisser]

Ah that looks like a bug maybe, I'll check out your branch and take a look. It's seems to be related to fetching to the resolving current version of that dependency.

As for the version selector, that is indeed global currently, like it was with the dependency versions plugin setup, but having one as a default + overrides for additional catalogs might make sense. You could use a project property for now to override the selector based on the property and run the specific update task for each catalog with the property set or not.

[hvisser]

@jamesward I've checked and added #129 for the null pointer and #130 for version selectors overrides per catalog so that I can track those separately. Thanks for trying it out and floating that #129 issue, I already tried with a few kmp things, but there seem to be more dragons ;)

[ben-manes]

I just want to say that I am perfectly happy to see you switch to your own resolver, while also being very glad that the versions plugin was helpful before that. The refreshVersions plugin also followed that path for richer control, proving out an extension idea and then evolving as its authors saw fit. If like them you learn a bit about how to write that resolver from my plugin, warts and all, that's a win.

I honestly did not think the versions plugin would still be around, closing in on 12 years, after writing it as a weekend project when learning Gradle (that's gradle 1.0). I had originally hoped they'd incorporate my forum post as a standard report, as it seemed like missing core functionality that merely scripted their apis. All my other plugins written at that time (flyway, jooq, jsonSchema2Pojo) were handed off to their parent projects, only that one stubbornly wasn't. I scratched my itch and kept it compatible with a lot of amazing help, but it shouldn't outlive its usefulness or become a burden. So if you find your own resolver reduces your woes and let's you do more, that's great.

I know how much time and effort a plugin takes to maintain, unexpectedly when it may feel "done", so thank you for efforts!

[hvisser]

@ben-manes If it wasn't for your plugin, I wouldn't probably started this, so thanks a lot for creating it! Twelve years is a looong time for a plugin :) I could still depend on the versions plugin, but there are some often reported "issues" that relate to what the version plugin reports and do not always map correctly on to the TOML file. For example, dependencies that are in the TOML file but unused (and kept by the user) won't be updated, which can be unexpected. That's not the fault of the versions plugin at all by the way. I hope that switching the resolver will sort out some of these behaviours at least, we'll see I guess :D

[ben-manes]

For example, dependencies that are in the TOML file but unused (and kept by the user) won't be updated, which can be unexpected.

Oh, one trick that I've used in my own builds is to create an unused configuration and add the dependencies to it. That won't be resolved in a normal build but will be picked up by the plugin's configuration scan. That way I could report on the bundled tool versions, e.g. pmd or checkstyles.

There are other known quirks and it is tiring to track them down. If I was in your shoes then I'd also want my own resolver to feel empowered when fixing issues and to add workarounds that made sense for my project. I hope it works out really well!