Sub component implementation inconsistent between different parent components in regards to scopes.

Version 2.7, & 2.8 Consumption is in a large android project, the issue only manifests itself in my androidTest src set component.

Component and scope layout is: AppComponent/ActivityComponent/ViewComponent where App component is @Singleton the activity component has a custom scope, and the view component has a custom scope.

Inside of my androidTest src set I create a ActivityTestComponent that is @Singleton and includes the ActivityComponent as a sub component. This allows me replace the majority of my object graph with mocks and give the activity the test component version of its component in its test run.

Problem that is occurring is the ViewComponent generated as a sub class of the test component is not correctly wrapping the objects provided in the double check provider.

AppCompImpl.java.txt TestCompImpl.java.txt

I’ve tried to replicate in a small sample project but the trivial version of this component layout has not produced the issue.

ActivityComponent is added as a sub component of the AppComponent via the @Module(subcomponent) and a @Binds @IntoMap @ClassKey on the component builder type. ActivityComponent is added as a sub component of the ActivityTestComponent via a method directly exposing the ActivityComponent.Builder on ActivityTestComponent.

[gk5885]

@trevjonez, the problem is two-fold:

1. Nothing about your scope is Dagger-specific. The Dagger processor only runs on Dagger types and @Scope is part of JSR 330, not Dagger.
2. If Dagger were to validate things like @Scope annotations, it would have had to have run on that class in order to have caught the error (because source retention wouldn’t have been retained in the class file).

That creates a semi-awkward situation in which you would potentially run the Dagger processor on build targets that contain no Dagger types just to get the extra static analysis. If you’re going to commit to running static analysis in the first place, Error Prone is the better choice because it will give you more complete analysis and suggested fixes.

[tbroyer]

That creates a semi-awkward situation in which you would potentially run the Dagger processor on build targets that contain no Dagger types just to get the extra static analysis.

Well, you sort-of have to do it already, for classes with @Inject, if you don’t want the message telling you to “run Dagger on that class”. Not for static analysis only, but still.

That said, I agree that it’s not Dagger’s role to check the retention of scope annotations.