-
-
Notifications
You must be signed in to change notification settings - Fork 417
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
Architecture change to support configuration cache in a proper way #857
Comments
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.
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. |
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:
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.
The text was updated successfully, but these errors were encountered: