ExperimentalVersionCatalogUpdateTask does not work with configuration cache

[sgybas]

Describe the issue
Running versionCatalogUpdate without the version plugin as desribed in #125 reports problems when the Gradle configuration cache is used. A simmilar issue was reported in #103 when using the version plugin.

Steps to reproduce
Run ./gradlew --configuration-cache -Pnl.littlerobots.vcu.resolver=true versionCatalogUpdate in any project. I'm using version-catalog-update 0.8.4 with Gradle 8.10.2:

> ./gradlew --configuration-cache -Pnl.littlerobots.vcu.resolver=true versionCatalogUpdate

6 problems were found storing the configuration cache, 2 of which seem unique.
- Task `:versionCatalogUpdate` of type `nl.littlerobots.vcu.plugin.ExperimentalVersionCatalogUpdateTask`: cannot serialize Gradle script object references as these are not supported with the configuration cache.
  See https://docs.gradle.org/8.10.2/userguide/configuration_cache.html#config_cache:requirements:disallowed_types
- Task `:versionCatalogUpdate` of type `nl.littlerobots.vcu.plugin.ExperimentalVersionCatalogUpdateTask`: invocation of 'Task.project' at execution time is unsupported.
  See https://docs.gradle.org/8.10.2/userguide/configuration_cache.html#config_cache:requirements:use_project_during_execution

[hvisser]

It's as compatible as it can be, but full compatibility is not possible (AFAIK) due to the restrictions on using project which is needed to resolve dependencies. I think that in practice this shouldn't be a big problem because the task is not a task that is core to your build. It should still load the configuration cache, it just can't serialise the cache to disk.

I've marked the task as such, that's why you are seeing warnings and not errors.

So I'm afraid that there's not much more I can do here, but I'm open to ideas ;)

[sgybas]

Thanks a lot for your explanation. I completelty agree that the warning is not a big problem at all since the task is not run with every build.

I filed this issue after watching The road to Gradle 9. The speakers mentioned that in the (far) future Gradle will only work with the configuration cache enabled. I'm not sure if a plugin will still be able to declare that is not compatible with the configuration cache.

If ExperimentalVersionCatalogUpdateTask can not be made to work with the configuation cache, maybe sticking with the versions plugin is the better choice?

[hvisser]

The versions plugin has the same issue. If Gradle is going to supply some API to get to the dependencies for Gradle 9 that would probably fix most issues, especially after the new resolver is the default, because that also eliminates another issue with Gradle 9, see #122.

I'll revisit this issue when I remove the dependency on the versions plugin to see if I can further improve this or if marking the task as incompatible is all that's possible for now.