Processor error on missing type while traversing too far up component dependency chain.

[JakeWharton]

Module 'test-a':

public final class A {
  @Inject A() {}
}

@Component
public interface ComponentA {
  A a();
}

Module 'test-b' which has implementation project(':test-a'):

public final class B {
  @Inject B(A a) {}
}

@Component(dependencies = ComponentA.class)
public interface ComponentB {
  B b();
}

Module 'test-c' which has implementation project(':test-b'):

public final class C {
  @Inject C(B b) {}
}

@Component(dependencies = ComponentB.class)
public interface ComponentC {
  C c();
}

fails with:

> Task :test-c:compileDebugJavaWithJavac FAILED
error: cannot access ComponentA
  class file for test.a.ComponentA not found
  Consult the following stack trace for details.
  com.sun.tools.javac.code.Symbol$CompletionFailure: class file for test.a.ComponentA not found
1 error

which makes sense, because 'test-c' isn't meant to see 'test-a' as it's an implementation detail of 'test-b', but why is Dagger in 'test-c' trying to do anything with ComponentA? Once it reaches ComponentB and sees the required B type exposed shouldn't it stop?

[ronshapiro]

We check to make sure there's no scope cycle in the dependency chain. The following would be an error

@Blue
@Component
public interface ComponentA {
  A a();
}

@Yellow
@Component(dependencies = ComponentA.class)
public interface ComponentB {
  B b();
}

@Blue
// ^ cycle! Maybe you meant @Green?
@Component(dependencies = ComponentB.class)
public interface ComponentC {
  C c();
}

There may be other reasons - a full stack trace may help to find the one you're encountering but this is the first one that comes to mind.

[JakeWharton]

Hmm that message is the entirety of the output from javac when invoked by itself outside of Gradle. No stacktrace from the processor.

[aarmstrong128]

This is hurting my team too (50+ developers). Let me know if you need any help reproducing or making progress.

[ronshapiro]

I don't think there's much to do here in terms of making progress - this is working as intended.

You can subvert this by defining dummy base-interfaces for your components and using those as the dependencies. Something like this:

interface Dependency {
  MyType myType();
  void inject(Thing thing);
}

@Component(modules = ...)
interface DependencyImpl extends Dependency {}

@Component(dependencies = Dependency.class)
                          ^ note, not DependencyImpl.class
interface MyComponent {
  ...
}

But that's definitely a hack, and could expose you to weird scope cycles.

[hongbinhuang]

Hi Ron,
As you mentioned, the hack could cause weird scope cycles. I think Dagger should honor Gradle's definition of "implementation" dependency and do scope cycle check through some other way instead.

[ronshapiro]

There is no way for dagger to know that information.

[Nimrodda]

@ronshapiro I bumped into the same issue - trying to modularize our app and having a component in each module. We currently have the main app module's AppComponent depending on a library's component in datasource module and datasource by itself depends on another library module that also exposes a component. We get the same compilation error.

I tried to add scopes for each component, but that didn't change anything.

I've recreated this setup in a sample app https://gitlab.com/codepond/dagger-modules

It would be great if you could have a look.

Thanks and Happy TuBiShvat! :)

[ronshapiro]

We fully understand the issue you're seeing, that's not the problem.

I think the best recommendation I have now is not to use implementation with dagger components in your component dependencies chain.

[Nimrodda]

Thanks for the tip, but the main reason we are modularizing the app is to improve build time using implementation so that's not an option for us.

In a post you made a few days ago you said this is working as intended, is this still the case? So we're not going to see a fix for this?

[hongbinhuang]

Hi @ronshapiro , we are also modularizing our app with reducing build time as one of the main goals and I can imagine more developers will run into same situation. So hope you guys can figure out a solution. Thanks!

[notsatyarth]

The implementation , api model also allows me to abstract the inner workings of a a module. I understand why Dagger would need to see the entire graph. But is there any way to prevent the app module from getting transitive dependencies (which would happen if we use api)which it does not require?

setting transitive as false while getting the dependency is not an option since I would like to make only a few dependencies(like internal custom modules) to not leak abstractions. External library dependencies would still remain transitive

[radityagumay]

@JakeWharton i also face a case like that. we use android-module to separate our codebase depend on their responsibility. instead we create dagger-module and dagger-component inside each
android-module. we create those dagger-dependency inside app, then we have flat-dependency.

each android-module has their implementation details. but, we create dagger-dependency inside app. that hack that we did.

this approach does not solve if we have a too deep implementation of dagger modularization.

[hongbinhuang]

Hi @radityagumay, are your "android-module" gradle modules, and by "flat-dependency", do you mean you only have 2 levels of modules, appreciate it if you can share a sample project. Thanks!