Includes visibility validation is too strict

The following component is valid:

@Component(modules = {
    ModuleIncludes.StringModule.class,
    ModuleIncludes.IntegerModule.class
})
interface ModuleIncludes {
  String string();

  @Module
  abstract class StringModule {
    @Provides static String string(Integer value) {
      return value.toString();
    }
  }

  @Module
  abstract class IntegerModule {
    @Provides static Integer value() {
      return 2;
    }
  }
}

But if I change it to

@Component(modules = ModuleIncludes.StringModule.class)
interface ModuleIncludes {
  String string();

  @Module(includes = IntegerModule.class)
  abstract class StringModule {
    @Provides static String string(Integer value) {
      return value.toString();
    }
  }

  @Module
  abstract class IntegerModule {
    @Provides static Integer value() {
      return 2;
    }
  }
}

Dagger will reject it:

src/main/java/com/example/ModuleIncludes.java:12: error: This module is public, but it includes non-public (or effectively non-public) modules. Either reduce the visibility of this module or make com.example.ModuleIncludes.IntegerModule public.
  abstract class StringModule {
           ^
src/main/java/com/example/ModuleIncludes.java:7: error: com.example.ModuleIncludes.StringModule has errors
@Component(modules = ModuleIncludes.StringModule.class)
                                                ^
2 errors

If the module isn’t require to be public when included directly on the component, why is it required to be so when declared as a transitive module?

[cgdecker]

Yeah, that seems like a slightly different issue than what we fixed in bfdecad. We should only be doing that validation for modules that are effectively public, i.e. those that may actually be referenced outside their package. I’ll get a fix in soon.

[ronshapiro]

@cgdecker