[Bug] Gradle multi-module project fails to build because a sub-project's compileReleaseJavaWithJavac is incorrectly flagged as NO-SOURCE by Gradle #5148
Description
We are seeing sporadic build failures in our large multi-module Android project with a stacktrace incriminating a [Dagger/MissingBinding] during the execution of :app:hiltJavaCompileRelease task.
They all look pretty similar and shares the same symptoms:
:app:hiltJavaCompileRelease FAILED
android-app/app/build/generated/hilt/component_sources/release/[...]/ApplicationRelease_HiltComponents.java:2664: error: [Dagger/MissingBinding] [...].Navigator cannot be provided without an @Provides-annotated method.
public abstract static class SingletonC implements FragmentGetContextFix.FragmentGetContextFixEntryPoint,
^
dagger.Lazy<[[...].Navigator]> is injected at
[[...].ApplicationRelease_HiltComponents.SingletonC] [...].UseCaseImpl(…, Navigator, …)
...
It is also requested at:
...
1 error
Obviously, the Navigator class is correctly @Binds in a module, in the features:F2FNegotiation:impl Gradle project.
We've tracked down a few interesting things while comparing two almost identical builds that are started seconds appart from each others and that are completely unrelated to the incriminated code. The first (A) failed, the second (B) succeeded.
In the Gradle Scan, this :features:F2FNegotiation:impl:compileReleaseJavaWithJavac task looked suspicious...
Only the second build (B) had input properties. The first build (A) had a Resulting outcome: NO_SOURCE
And here are the details of the tasks of both builds for this module. We can see NO-SOURCE for the compileReleaseJavaWithJavac, which means, the bindings from this module is not being compiled and therefore we endup in a build failure (in the unit tests that failed here, this was a NoClassDefFoundError on a Hilt generated class that should have been present).
So I tried to look up at one of compileReleaseJavaWithJavac predecessor (related to java compilation): javaPreCompileRelease that is flagged as FROM-CACHE.
Looking at the corresponding build cache key, it was originating from a different module: :domains:P2PTransactions:javaPreCompileRelease during a linting task (i.e. :domains:P2PTransactions:lintAnalyzeRelease).
The cache entry content was only consisting of METADATA and this tree-annotationProcessorListFile
{"hilt-compiler-2.59.2.jar (com.google.dagger:hilt-compiler:2.59.2)":"KSP_PROCESSOR","dagger-compiler-2.59.2.jar (com.google.dagger:dagger-compiler:2.59.2)":"KSP_PROCESSOR"}
I'm not sure if this is intented or not, and if it is the cause or the consequence. But at this point we have no idea where to continue our investigations.
We've been able to reproduce this on CI & local envs, but not consistantly, and not able to make a small reproducer project yet.
We are using these dependencies:
- Android Gradle Plugin: 9.1.0
- Kotlin Gradle Plugin: 2.3.20
- Dagger/Hilt: 2.59.2
- KSP: 2.3.6
- Gradle: 9.4.1
- JDK: 25 (temurin)
And our KSP/Hilt configuration is currently using this:
extensions.configure<HiltExtension> {
enableAggregatingTask = true
}
extensions.configure<KspExtension> {
// https://dagger.dev/hilt/flags.html#disable-install-in-check
arg("dagger.hilt.disableModulesHaveInstallInCheck", "true")
// https://dagger.dev/dev-guide/compiler-options.html#fastinit-mode
arg("dagger.fastInit", "ENABLED") // default value with Hilt
// https://dagger.dev/dev-guide/compiler-options#ignore-provision-key-wildcards
arg("dagger.ignoreProvisionKeyWildcards", "ENABLED")
// https://dagger.dev/dev-guide/compiler-options#useBindingGraphFix
arg("dagger.useBindingGraphFix", "ENABLED")
// https://www.zacsweers.dev/dagger-party-tricks-refactoring/
arg("dagger.warnIfInjectionFactoryNotGeneratedUpstream", "ENABLED")
}And the Gradle properties contains these relevant settings:
org.gradle.caching=true
org.gradle.configuration-cache=false
org.gradle.configureondemand=false
org.gradle.parallel=true
kotlin.incremental=false