Architecture change to support configuration cache in a proper way

[ILikeYourHat]

This isn't a specific issue, rather an opportunity to talk about this plugin architecture.

Let's face it: this project has many issues related to the caching mechanism, like this and this. Now, after bumping Android Cache Fix Plugin and/or Gradle Doctor Plugin, I have the following logs for each module, caused by AboutLibraries behaviour:

Configuration 'debugUnitTestRuntimeClasspath' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.

This is not something that is failing my build, but it is indicating that there is something basically wrong in the way this plugin works. The main issue is probably the way this plugin "injects" itself into every module from the top one, after they are evaluated. I've got a feeling that this approach will cause even more issues over time. Looking at recent Gradle development, it is focused on isolating modules logic from other modules logic, and AboutLibraries plugin is doing something completely opposite.

My idea is: this plugin should be applied in the same way every other multi-module plugin is applied, this is: by adding this plugin to every module separately. Look for example at Detekt Plugin, which works exactly this way, and afaik has no issues with cache. What do you think about this? It is possible for AboutLibraries to adopt the same approach?

I know collecting dependencies from the project is not an easy task, and I appreciate the work you have already done. I just want to still be able to use this library, while keeping all the dependencies up-to-date and benefit from the latest performance improvements. Unfortunately, this task is becoming harder and harder over time.

[mikepenz]

Good day @ILikeYourHat

Thank you for the report. The last few weeks have been very busy and I haven't had a chance to look more into it, and I am not sure yet when I will be able to.

A possible work-around for all those problems may be to disable the registration as part of the android build pipelines, and having the CI build the dependencies (or making it a step of the release process) with the results to be included as part of the SCM.

I agree though that there are problems to the caching, specifically the configuration cache system. I see that there are updates being made in gradle in regards to retrieving the information we need, but so far past tries have not been sufficient.

At this current time I may not be able to spend the amount of time on this matter, as I'd need to, to find a proper solution for all scenarios.

That being said, if somebody with more time, or more knowledge about gradle would like to look into this. It would be immensely appreciated.