New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate to Dagger 2.0 #601

Open
csmith opened this Issue May 20, 2015 · 1 comment

Comments

Projects
None yet
1 participant
@csmith
Member

csmith commented May 20, 2015

We should switch to using Dagger 2.0.

Components should allow plugin dependency injection to be done much more nicely.

@csmith csmith self-assigned this May 20, 2015

csmith added a commit to csmith/DMDirc that referenced this issue May 20, 2015

Ensure module methods have unique names.
Dagger 2.0 appears to require each method in a module to have a
unique name. In some cases we've used overloads with the same name.

Also, remove a bunch of boilerplate javadoc.

Issue #601

csmith added a commit to csmith/DMDirc-Parser that referenced this issue May 22, 2015

@csmith csmith removed their assignment Feb 13, 2016

@csmith

This comment has been minimized.

Show comment
Hide comment
@csmith

csmith Feb 26, 2016

Member

I don't think this is actually possible because of how Dagger 2 currently does submodules.

In our current implementation, the client defines a ClientModule (& dependencies) and plugins define their own FooModule which extends ClientModule. This gives them access to the dependency graph from the client.

In Dagger 2 there are two options: the ClientModule has a factory method to create a FooModule (not going to work), or FooModule only gets the types that are injectable by ClientModule (i.e., Main and a couple of others).

We'd need to rethink how plugin dependency injection works in order to switch to Dagger 2. I'm not sure that's a bad thing, as we can start defining a proper API, but it's a massive project beyond just bumping Dagger to 2.x.

Member

csmith commented Feb 26, 2016

I don't think this is actually possible because of how Dagger 2 currently does submodules.

In our current implementation, the client defines a ClientModule (& dependencies) and plugins define their own FooModule which extends ClientModule. This gives them access to the dependency graph from the client.

In Dagger 2 there are two options: the ClientModule has a factory method to create a FooModule (not going to work), or FooModule only gets the types that are injectable by ClientModule (i.e., Main and a couple of others).

We'd need to rethink how plugin dependency injection works in order to switch to Dagger 2. I'm not sure that's a bad thing, as we can start defining a proper API, but it's a massive project beyond just bumping Dagger to 2.x.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment