Ensure new Gradle Configuration Cache is supported

[ZakTaccardi]

Check out gradle/gradle#13490

[ben-manes]

PRs are welcome.

It is time for the Gradle team to step up and support this plugin's feature, either natively or by becoming the maintainers. It is a basic dependency management capability that was okay to delegate to the community around Gradle 1.x time frame as a very small core team working as consultants. After 8 years, funding / revenue, and a much larger team, its past time that they should take responsibility.

[ZakTaccardi]

Agreed. Relevant issue is gradle/gradle#13498

[re-thc]

4 problems were found storing the configuration cache, 2 of which seem unique.
- Build file 'build.gradle': read system property 'java.runtime.name'
  See https://docs.gradle.org/6.7-rc-3/userguide/configuration_cache.html#config_cache:requirements:undeclared_sys_prop_read
- Task ':dependencyUpdates' of type 'com.github.benmanes.gradle.versions.updates.DependencyUpdatesTask': invocation of 'Task.project' at execution time is unsupported.
  See https://docs.gradle.org/6.7-rc-3/userguide/configuration_cache.html#config_cache:requirements:use_project_during_execution

Tried configuration cache and got the following error.

[ben-manes]

We recurse the multi-project build to resolve all configuration dependencies. That limitation of the configuration cache means its incompatible with this behavior.

If there was a way to capture the configurations during the init phase then maybe the existing logic would work as expected. I suppose that could use an afterEvaluate to build a multi-map of the project.name => configurations, so that it is fully backwards compatible in the outputs.

The alternative would be to follow the jacoco plugin's approach of adding per-project tasks and a root aggregate task, so that projects are not traversed. That would have the benefit of parallel project resolution, but also be an invasive change.

PRs are welcome if someone wants to try fixing this. Otherwise you might conditionally apply the plugin as its not needed in most builds, e.g. use it only on your CI, a github action, or passing in a project property to enable.

[eygraber]

Not sure if you could use this, but I managed to collect dependencies in a way that works with configuration caching. It's not the most performant (because some of the collection happens outside of the task), but it's not bad - https://gist.github.com/eygraber/482e9942d5812e9efa5ace016aac4197

Also see gradle/gradle#12871

[eygraber]

Some work happening along those lines in another library - mikepenz/AboutLibraries#677

[tprochazka]

I don't understand how this plugin can break compilation cache at all, it runs only on demand, right? So it should do nothing until I call the right task.

[eygraber]

True to some degree (other than creating tasks eagerly), but some of us have very long configuration times (in the order of minutes), and it would be nice to not have to wait for that when running these tasks.

[eygraber]

Gradle 7.4 is introducing a task opt-out for the configuration cache.

Also Gradle 7.5 should have more support for making this plugin compatible with the configuration cache.

[eygraber]

I tested the notCompatibleWithConfigurationCache function in 7.4-rc-2 and it seemed to work!

[ben-manes]

nice! A PR is welcome. 😉

I think we'd need to guard with metaClass.respondsTo to for backwards compatibility, like we do elsewhere.

gradle-versions-plugin/src/main/groovy/com/github/benmanes/gradle/versions/updates/Resolver.groovy

Line 420 in 3a6f716

configuration.metaClass.respondsTo(configuration, "getDependencyConstraints")

[eygraber]

#585

[ben-manes]

Thanks @eygraber! 🙂