You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're seeing very long fingerprinting times in some hilt tasks.
Our app module's hiltJavaCompileDebug and hiltJavaCompileDebugUnitTest spends over 1 minute to fingerprint inputs on CI, only to determine it's up to date. This is by far the longest tasks in our project.
It's possible this is unavoidable but if possible this should be reduced.
We expect the fingerprinting of inputs to be decently large for hiltJavaCompileDebug but over a minutes does sound large for something that is meant to prevent the task from executing. The inputs are possibly very large, they are essentially all of your app's runtime classpath, i.e. all of those 482 modules and their transitive dependencies.
This is by design since Hilt perform modules and entry points aggregations at the root (the app), and then creates a big @Component for Dagger. Then Dagger's ComponentProcessor and its superficial validator visit every class that is reachable from the created @Component class, including class referenced in public APIs.
I do believe it is likely including too many dependencies, clearly a 2nd level transitive dependency of a third-party library will not be reachable from Dagger, the challenge for us will be figuring out how we can reduce the inputs.
One workaround you can try is to disable the aggregation (via enableAggregatingTask = false in the Hilt Plugin) and manually include every dependency that Dagger will need at the app's module. Most of the time if there is a missing dependency there will be a compilation error, but the dangerous part is modules with multibindings, a missing dependency might mean a missing multibinding value and that can be hard to diagnose and track. This approach is not great but is what we should strive to aim for with the aggregation, to be as equivalent as if the project was correctly configured in terms of api and implementation dependencies for Dagger.
I'll try to raise this with the team and come back if we end up with a plan. Let me know if you have more questions.
We're seeing very long fingerprinting times in some hilt tasks.
Our app module's
hiltJavaCompileDebug
andhiltJavaCompileDebugUnitTest
spends over 1 minute to fingerprint inputs on CI, only to determine it's up to date. This is by far the longest tasks in our project.It's possible this is unavoidable but if possible this should be reduced.
Gradle: 8.10
Dagger: 2.52
Java: 21
AGP: 8.6.0
Module count: 482
The text was updated successfully, but these errors were encountered: