When nested overriding modules provide the same binding, outermost override should "win"

[adennie]

A module can't override an included module's provider for a particular type if the included module also overrides a third module. For example:

public static class Thing {
}

@Module
public static class Module1 {
}

@Module(overrides= true, includes = Module1.class)
public static class Module2 {
   @Provides
    public Thing provideThing() {
        return new Thing();
    }
}

@Module(overrides= true, includes = Module2.class)
public static class Module3 {
   @Provides
    public Thing provideThing() {
        return new Thing();
    }
}

This results in "Duplicate bindings for Thing: Module3.provideThing(), Module2.provideThing()." This is because FullGraphProcessor.processCompleteModule detects "clobbering" within the map of override bindings and records it as an error.

It seems like it should be possible to keep track of the hierarchy of the modules, and have the most-overriding module "win".

[swankjesse]

No, I don't think this complexity is worthwhile. Module overrides support only two levels, most commonly used for production and test. Precedence rules are not worth the complexity of implementation and we want to discourage users from building apps that would need them.