Dagger 2.10 Subkomponente Generator - Injector Validierung fehlschlägt

Question

Ich versuche, eine Anmerkung Prozessor zu schaffen, die meine MVP Ansichten verarbeiten (Fragmente) zu automatisch generierten Subkomponenten (ähnlich https://github.com/lukaspili/Auto-Dagger2, aber für die neuen Dagger 2.10 android Injektoren)

Bisher habe ich in der Lage gewesen, entsprechende Dateien zu generieren, aber es ist eine seltsame Fehlermeldung, wenn

Error:(22, 58) error: @dagger.android.support.FragmentKey methods should bind dagger.android.AndroidInjector.Factory<? extends android.support.v4.app.Fragment>, not dagger.android.AndroidInjector.Factory<? extends android.support.v4.app.Fragment>. See google.github.io/dagger/android

Die Struktur des Werksmodul und Subkomponente Dateien erzeugt Komponenten Kompilieren sollte so schnell, weil richtig, wie ich die generierten Klassen copy-paste und eine regelmäßige Klassen (beide Werksmodul und Subkomponente) und verwenden echte Klassen statt erzeugt diejenigen erstellen, wird die Meldung nicht mehr angezeigt und Kompilierung erfolgreich

Es ist wie das Problem scheint liegt in AndroidMapKeyValidator (link), wo !MoreTypes.equivalence().equivalent(returnType, intendedReturnType) Anruf anscheinend nicht, aber ich habe nicht viel von einer Erfahrung Debug-Annotation-Prozessoren, so dass ich weiß nicht genau, warum ...

Kann vielleicht jemand helfen, wo man nach dem Problem sucht? Dank

FYI: MyFragment hat android.support.v4.app.Fragment

---

Meine Dateien erweitern:

generiert Fabrik @Module public interface BuildersModule { @Binds @IntoMap @FragmentKey(MyFragment.class) abstract AndroidInjector.Factory<? extends Fragment> factory(MySubcomponent.Builder builder); }

generiert Subkomponente @Subcomponent(modules = MyModule.class) public interface MySubcomponent extends AndroidInjector<MyFragment> { MyPresenter presenter(); @Subcomponent.Builder abstract class Builder extends AndroidInjector.Builder<MyFragment> {} }

Answer 1

Wenn jemand inte ist in Lösung gelost:

Ich fand heraus, dass aus irgendeinem Grund, Referenzen von ClassType -s während der Kompilierzeit des Projekts verglichen nicht identisch sind, wenn die generierte Methode validiert.

Und diese Referenzen, trotz der Tatsache, dass sie auf die gleiche Klasse verweisen, werden in auto-common Bibliothek in EqualVisitor.visitDeclared Methode auf Gleichheit überprüft. Offenbar kann dies ein Fehler in auto-common sein, weil Elemente in visitDeclared durch Objektreferenz verglichen werden, aber nicht Typenreferenz.

So Abhilfe ist hier zu Verwendung lokaler Fest Kopie von auto-common Bibliothek und ausschließen alle Abhängigkeiten der ursprünglichen Bibliothek.

//TODO think if this is the correct solution to cast both elements 
//return aElement.equals(bElement) 
return ((TypeElement) aElement).getQualifiedName().equals(((TypeElement) bElement).getQualifiedName()) 
     && equal(a.getEnclosingType(), b.getEnclosingType(), newVisiting) 
     && equalLists(a.getTypeArguments(), b.getTypeArguments(), newVisiting); 

---

ich habe noch zu prüfen, warum diese Verweise nicht gleich sind, und ich habe zu denken, wie die Gleichheitsprüfung in auto-common richtig fixiert werden kann (ich nutze einfach ein quickfix), bevor ein Problem in auto-common Einreichung Repo.