Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ensure new Gradle Configuration Cache is supported #410

Closed
ZakTaccardi opened this issue Jul 17, 2020 · 13 comments
Closed

Ensure new Gradle Configuration Cache is supported #410

ZakTaccardi opened this issue Jul 17, 2020 · 13 comments

Comments

@ZakTaccardi
Copy link

@ZakTaccardi ZakTaccardi commented Jul 17, 2020

Check out gradle/gradle#13490

@ben-manes
Copy link
Owner

@ben-manes ben-manes commented Jul 17, 2020

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
Copy link
Author

@ZakTaccardi ZakTaccardi commented Jul 17, 2020

Agreed. Relevant issue is gradle/gradle#13498

@re-thc
Copy link

@re-thc re-thc commented Oct 6, 2020

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
Copy link
Owner

@ben-manes ben-manes commented Oct 6, 2020

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
Copy link
Collaborator

@eygraber eygraber commented Aug 25, 2021

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
Copy link
Collaborator

@eygraber eygraber commented Oct 20, 2021

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

@tprochazka
Copy link

@tprochazka tprochazka commented Oct 29, 2021

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
Copy link
Collaborator

@eygraber eygraber commented Oct 29, 2021

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
Copy link
Collaborator

@eygraber eygraber commented Jan 17, 2022

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
Copy link
Collaborator

@eygraber eygraber commented Feb 4, 2022

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

@ben-manes
Copy link
Owner

@ben-manes ben-manes commented Feb 4, 2022

nice! A PR is welcome. 😉

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

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

@eygraber
Copy link
Collaborator

@eygraber eygraber commented Feb 4, 2022

#585

@ben-manes
Copy link
Owner

@ben-manes ben-manes commented Feb 4, 2022

Thanks @eygraber! 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants