Convince Dagger to support automatic module discovery in a general way

We’ve now hit the rule of three with public use cases for this feature:

• @ContributesAndroidInjector
• @AssistedInject
• @InflationInject

The first one has massively superior ergonomics because its generated bindings can be auto-discovered and bound into the graph. It gets this by virtue of being built by the Dagger team. Lucky!

The latter two are in this repo and do not receive auto-discovery. Instead, we force the consumers to annotate a module such that we generate a sibling module which contains only unscoped bindings. This lets us talk to Dagger where we otherwise cannot. It has devastating effects on incremental compilation and incremental annotation processing since both need to aggregate all usages in a compilation unit. And finally, it has annoying ergonomics because you have to reference generated code directly and manually include a module.

An additional hypothetic use case as well as the general Dagger feature request is tracked here: https://github.com/google/dagger/issues/869. This also would eliminate the need for Dagger to build everything as a first-party feature (e.g., https://github.com/google/dagger/issues/935) and allow people to mix-in behavior from other libraries.

We should come up with a proposal for the general mechanism on which Dagger’s @ContributesAndroidInjector and our @AssistedInject and @InflationInject can be built.

[filipkowicz]

Do you have any update from Dagger side?

[JakeWharton]

FYI: https://github.com/google/dagger/issues/1825