A fast dependency injector for Android and Java.

Square

Last update: Jan 5, 2023

Related tags

Dependency Injection dagger

Overview

Dagger 1

A fast dependency injector for Android and Java.

Deprecated – Please upgrade to Dagger 2

Square's Dagger 1.x is deprecated in favor of Google's Dagger 2. Please see the migration guide for help with the upgrade.

Download Dagger 1

You will need to include the dagger-${dagger.version}.jar in your application's runtime. In order to activate code generation you will need to include dagger-compiler-${dagger.version}.jar in your build at compile time.

In a Maven project, one would include the runtime in the dependencies section of your pom.xml (replacing ${dagger.version} with the appropriate current release), and the dagger-compiler artifact as an "optional" or "provided" dependency:

<dependencies>
  <dependency>
    <groupId>com.squareup.dagger</groupId>
    <artifactId>dagger</artifactId>
    <version>${dagger.version}</version>
  </dependency>
  <dependency>
    <groupId>com.squareup.dagger</groupId>
    <artifactId>dagger-compiler</artifactId>
    <version>${dagger.version}</version>
    <optional>true</optional>
  </dependency>
</dependencies>

You can also find downloadable .jars on Maven Central. You'll need Dagger, JavaPoet, and javax.inject.

Snapshots of the development version are available in Sonatype's snapshots repository.

License

Copyright 2012 Square, Inc.

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

   http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

Comments

Explain how to add dagger to Eclipse project

I tried adding dagger to an android eclipse project. dagger-0.9.jar library was added to java build path. Under java compiler annotation processor was enabled, and dagger-compiler-0.9.jar was added as factory path. Consistently get Internal compiler error: java.lang.NoClassDefFoundError: Could not initialize class dagger.internal.codegen.ProvidesProcessor at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) BuildConfig.java

How about a simple "how-to" on adding dagger support to eclipse - not everyone is using Marven. You guys did a good job explaining how to use the framework but installation instructions suck.
invalid

opened by macsux 62
Codegen should survive ProGuard

See this G+ thread & branch from @cermakcz: https://plus.google.com/u/0/117878637395157279424/posts/HMiCxi4wh7J https://github.com/cermakcz/dagger/compare/obfuscatable
enhancement

opened by swankjesse 35
Runtime parent bindings are requested for some compile time bound @Inject annotated classes
I have found a few cases in which start up will take longer than necessary due to dagger reflectively analyze the dependencies of a class.

Two of the cases:

Abstract classes - I have a few abstract classes that have no injected fields. I can't annotate the constructors for these classes with @Inject (dagger won't compile the class if I do) and so I don't know of a way that I can get the annotation process to create an $InjectAdapter class for the abstract base class. So, instead, at runtime I have to reflectively evaluate the inheritance chain when I try to inject an instance of the impl.

Classes that were not compiled using the annotation processor - A few times I use a framework for FrameworkClass and want to inject an instance of MyFrameworkClass (which extends FrameworkClass). FrameworkClass was not written with a DI framework in need and thus I know that there is no need to inject into that class. However, the same issue as above applies - the compile time binding for MyFrameworkClass requests a binding for the supertype.

In general it would be nice if there was a way to opt out classes from needing bindings. For example:

@Module { entryPoints = {}... noBindingsNeeded = {FrameworkClass.class} }

Alternatively we could also annotate the class (but I would prefer the above, since to me this is analagous to requesting static injection and belongs on the Module)

@NoSuperInject class MyFrameworkClass extends FrameworkClass { }
enhancement wontfix
opened by rwinograd 34
Spin off a new project to replace Roboguice

I don't know if you guys are already doing this, or have plans to but I'd be really interested in either participating in this, or starting this myself. It would be useful to write a replacement for Roboguice using Dagger instead of Guice.

opened by christopherperry 28
Added new static checks
Added the following checks:

Check for @Inject on a final field

Validate the use of scoping annotations

error if a scoping annotation is anywhere but a class or method

error if a scoping annotation is on an abstract class or interface

error if more than one scoping annotation is on an element where scoping is allowed

warning if a scoping annotation is on a method that is not a @dagger.Provides method

Validate the use of qualifier annotations

error of more than one qualifier annotation is on an element where qualifiers are allowed (this check was already present; I just moved it.)

error if a qualifier is anywhere but a field, method, or parameter

warning if a qualifier is on a non @dagger.Provides method

warning if a qualifier is on a parameter that is not a @dagger.Provides method parameter or an @Inject constructor parameter

warning if a qualifier is on a non-injectable field

Check that @Provides methods are only declared in modules

Warnings for misuse of qualifiers can be suppressed with @SuppressWarnings("qualifiers"), and warnings for misuse of scoping annotations can be suppressed with @SuppressWarnings("scoping").

Also, take a look at error-prone, where I've added lots of general DI checks. The checks in error-prone and here overlap largely, but there are a few that are only in error-prone. For example, I've written error-prone checks to fail if scope and qualifier annotations do not have runtime retention or if a scoping annotation has invalid targeting. (Not all of these checks have been merged into the main error-prone project yet, but if you want to take a look at what's coming, they're all in my error-prone fork). Also, error-prone has the benefit that it will do the static checks for all DI frameworks.
enhancement fixed
opened by sgoldfed 27
Recommend scope=provided to include dagger-compiler.

Using the compiler plugin wasn't picking up the code gen plugin reliably for me. Using optional means that everything that uses dagger-compiler needs an explicit dependency, even if they're depending on dagger implicitly.

opened by swankjesse 27

Should ObjectGraph.plus() use module objects or class objects

The class ObjectGraph has a plus method:

@Override public ObjectGraph plus(Object... modules)

Why does this method's parameter have Object type? It can cause confusion about whether we should pass in new FooModule() or FooModule.class.

I found this deeper in the code so probably both will work, but the use of plus still doesn't seem to be documented.

for (int i = 0; i < seedModulesOrClasses.length; i++) {
  if (seedModulesOrClasses[i] instanceof Class<?>) {
    ModuleAdapter<?> adapter = loader.getModuleAdapter((Class<?>) seedModulesOrClasses[i]);
    seedAdapters.put(adapter, adapter.newModule());
  } else {
    ModuleAdapter<?> adapter = loader.getModuleAdapter(seedModulesOrClasses[i].getClass());
    seedAdapters.put(adapter, seedModulesOrClasses[i]);
  }
}

Hope to get some clarification here or you write some javadoc there. Thanks.

opened by cykerway 22

Restructure the core code and projects

This pull request moves most of the code-generation into a separate maven project, and moves the related handling code for both generated code and reflection into separate packages.

At run-time, polymorphic dispatchers will attempt to process each act (linking, static injection, and module adapter handling) by dispatching that act to whatever handlers they've been configured with (currently hard-coded to be the Codegen version then the Reflective version in that order).

All decisions as to whether codegen or reflection or both (and in what order) are now encapsulated in (what used to be) ObjectGraph.get().

Lastly, ObjectGraph.get() is now Dagger.wire() which returns an ObjectGraph instance. (I left ObjectGraph.get() in temporarily to make this PR neutral to end-users. Not even deprecated. But we want to use get() for getInstance() and this change moves the ball.

opened by cgruber 22
Dagger 2: Require `@Inject` constructor for provision?
In Google's Dagger 2.x candidate we have a deviation from the normal assumptions about @Inject signals that we think will really clean things up, and we wanted to shop it to the main project, since it's the only substantial departure to Dagger 1.x semantics with respect to client code (that is, to non-configuration, non-module code). Namely, that for Bar to depend on Foo, Foo has to have an @Inject constructor in all cases, even if it uses members-injection.

context

One piece of context for this question is that in our 2.0 candidate, we've separated the notion of a provision binding from members-injection. Provision bindings (@Inject constructor or @Provides method) result in a Provider<T> being bound to the key, but members-injection (@Inject on a field or method) results in a MembersInjector<T> being bound. A class may have both a Provider<T> and a MembersInjector<T> if it is both instantiable by Dagger but also needs field/method injection. In that case, the Provider<T> concrete type depends on the MembersInjector<T>.

Because of this, it is vastly simpler, clearer, and lines up the developer's expectation of the generated code with the client code.

where it matters

The sticking point is the current Dagger behavior where a class can be both members-injectable and providable if it has an @Inject field, but a default or accessible no-args constructor, like so:

class Foo { @Inject Bar bar; }

The above can be depended upon, where in Dagger 2, we are proposing that it could not - it would be suitable for members injection but not provision. To have it be provided (to dependents) it would have to add an @Inject constructor like so:

class Foo { @Inject Bar bar; @Inject Foo() {} }

practicalities

For things like Activities, this is fine, since we won't be making Provider<? extends Activity> ever, since they can never be instantiated by Dagger anyway. They are injectable, and they will have a MembersInjector<T> created for them. But it adds a small amount of boilerplate to classes that were using field injection for convenience, readability, or possibly functional reasons, but didn't add a no-args @Inject constructor. In Dagger 2, we propose that they must, and that we never generate a Provider<T> (and therefore they will be invalid as a target for a dependency) unless they do so.

Non-dagger-constructable types can always, as now, be provided via @Provides methods, so this change is quite aside from that.

conclusion

We think this is a net improvement, conceptually, aligning the signals with the semantics a little more. It also cleans up the implementation of the generators and analyzers.
question design
opened by cgruber 19
Consistent iteration order between compiled and reflective set bindings

When adding to a set binding via ObjectGraph.create(initialSetBinding, appendToSet) there's a difference in the iteration order of the injected Set depending on whether it was added via FullGraphProcessor or ReflectiveModuleAdapter.

In the case of reflective, the first in the set binding corresponds to the first module.

In the case of annotation processed, the first corresponds to the second module.

I'm hoping we can ensure consistent iteration order regardless of whether set bindings are set reflectively or via the compiler.

opened by codefromthecrypt 19

ClassCastException in ValidationProcessor

I just got a java.lang.ClassCastException: com.sun.tools.javac.code.Attribute$Error cannot be cast to com.sun.tools.javac.code.Attribute$Class under 1.7.0_40. The error is happening because the @Module specifies a value for injects that is generated. So, in the first round of processing the value isn't a valid class because it doesn't exist yet, but in subsequent rounds (after the other processor has been invoked) it works fine. In fact, the Eclipse compiler handles this just fine.

It seems that Element.getAnnotation isn't safe to call in current versions of Java 1.7, but the bigger issue is probably that RuntimeExceptions are leaking out of the Dagger processors.

Here's the full stack trace:

java.lang.ClassCastException: com.sun.tools.javac.code.Attribute$Error cannot be cast to com.sun.tools.javac.code.Attribute$Class
    at com.sun.tools.javac.model.AnnotationProxyMaker$ValueVisitor.visitArray(AnnotationProxyMaker.java:190)
    at com.sun.tools.javac.code.Attribute$Array.accept(Attribute.java:215)
    at com.sun.tools.javac.model.AnnotationProxyMaker$ValueVisitor.getValue(AnnotationProxyMaker.java:165)
    at com.sun.tools.javac.model.AnnotationProxyMaker.generateValue(AnnotationProxyMaker.java:143)
    at com.sun.tools.javac.model.AnnotationProxyMaker.getAllReflectedValues(AnnotationProxyMaker.java:101)
    at com.sun.tools.javac.model.AnnotationProxyMaker.generateAnnotation(AnnotationProxyMaker.java:86)
    at com.sun.tools.javac.model.AnnotationProxyMaker.generateAnnotation(AnnotationProxyMaker.java:78)
    at com.sun.tools.javac.model.JavacElements.getAnnotation(JavacElements.java:108)
    at com.sun.tools.javac.model.JavacElements.getAnnotation(JavacElements.java:121)
    at com.sun.tools.javac.code.Symbol$ClassSymbol.getAnnotation(Symbol.java:888)
    at dagger.internal.codegen.ValidationProcessor.validateProvides(ValidationProcessor.java:75)
    at dagger.internal.codegen.ValidationProcessor.process(ValidationProcessor.java:67)
    at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:793)
    at com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:722)
    at com.sun.tools.javac.processing.JavacProcessingEnvironment.access$1700(JavacProcessingEnvironment.java:97)
    at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1029)
    at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1163)
    at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1108)
    at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:824)
    at com.sun.tools.javac.main.Main.compile(Main.java:439)
    ... 26 more

opened by gk5885 18

after add hilt { enableAggregatingTask = true } dependencies tasks faild

when I add the line hilt { enableAggregatingTask = true} error (Execution failed for task ':app:dependencies) happend

Execution failed for task ':app:dependencies'. Cannot change dependencies of dependency configuration ':app:hmsDebugAndroidTestRuntimeClasspath' after it has been included in dependency resolution. Use 'defaultDependencies' instead of 'beforeResolve' to specify default dependencies for a configuration.

The task fails when I add a flavor that starts with a letter greater than g

Example:

flavorDimensions "version" productFlavors{ hms{ dimension "version" } gms{ dimension "version" } }

opened by cquin89 0
sorting fields for deterministic order

When using reflection to get the fields from a class, the order of the fields is not guaranteed to be in any specific order. Some tests, like multiValueBindings_WithSingletonsAcrossMultipleInjectableTypes, may fail due to a different ordering returned by getDeclaredFields. This PR sorts the field array returned by getDeclaredFields to guarantee a deterministic order (in this PR, alphabetical order).

Please let me know if you want to discuss the changes more.

opened by contextshuffling 3
'No injectable members ...' is an error?
Consider that DeleteBastion class has no injectable members and I have a factory class as follows:

@Singleton public static class Factory { @Inject MembersInjector<DeleteBastion> injector; public DeleteBastion create(Regions region, Environment env) { DeleteBastion cmd = new DeleteBastion(region, env); injector.injectMembers(cmd); return cmd; } }

Compiling gives me the following error:

Error:(43, 8) java: No injectable members on DeleteBastion. Do you want to add an injectable constructor? required by DeleteBastion.Factory for Main

Now, the error message is pretty obvious since I don't have an injectable member in the DeleteBastion, but that is quite inconvenient. Right now I don't have an injectable member, but it is quite possible that I may have one in the future. Does that mean I need to manage this by commenting out code and uncommenting it when I do have an injectable member? Shouldn't this be a warning at most or am I missing something?
opened by rodlogic 1
dagger.internal.codegen.Util$CodeGenerationIncompleteException: Unknown type r eturned as
Hey Guys, We are facing problem while compiling our code using dagger 1.2.1. Can you please guide us how to resolve the issue. I am copying full stacktrace below. Your urgent help will be highly appreciated. Thanks. provided 'com.squareup.dagger:dagger-compiler:1.2.1'

:app:mergeReleaseResources :app:processReleaseManifest :app:processReleaseResources :app:generateReleaseSources :app:compileReleaseJavaWithJavac FAILED

FAILURE: Build failed with an exception.

What went wrong: Execution failed for task ':app:compileReleaseJavaWithJavac'.

dagger.internal.codegen.Util$CodeGenerationIncompleteException: Unknown type r eturned as .

Try: Run with --info or --debug option to get more log output.

Exception is: org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':app:com pileReleaseJavaWithJavac'. at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.ex ecuteActions(ExecuteActionsTaskExecuter.java:69) at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.ex ecute(ExecuteActionsTaskExecuter.java:46) at org.gradle.api.internal.tasks.execution.PostExecutionAnalysisTaskExec uter.execute(PostExecutionAnalysisTaskExecuter.java:35) at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.exec ute(SkipUpToDateTaskExecuter.java:64) at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execut e(ValidatingTaskExecuter.java:58) at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecu ter.execute(SkipEmptySourceFilesTaskExecuter.java:52) at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter .execute(SkipTaskWithNoActionsExecuter.java:52) at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execut e(SkipOnlyIfTaskExecuter.java:53) at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter .execute(ExecuteAtMostOnceTaskExecuter.java:43) at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTa skWorker.execute(DefaultTaskGraphExecuter.java:203) at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTa skWorker.execute(DefaultTaskGraphExecuter.java:185) at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorW orker.processTask(AbstractTaskPlanExecutor.java:62) at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorW orker.run(AbstractTaskPlanExecutor.java:50) at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor.process(Defaul tTaskPlanExecutor.java:25) at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter.execute(Defau ltTaskGraphExecuter.java:110) at org.gradle.execution.SelectedTaskExecutionAction.execute(SelectedTask ExecutionAction.java:37) at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecute r.java:37) at org.gradle.execution.DefaultBuildExecuter.access$000(DefaultBuildExec uter.java:23) at org.gradle.execution.DefaultBuildExecuter$1.proceed(DefaultBuildExecu ter.java:43) at org.gradle.execution.DryRunBuildExecutionAction.execute(DryRunBuildEx ecutionAction.java:32) at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecute r.java:37) at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecute r.java:30) at org.gradle.initialization.DefaultGradleLauncher$4.run(DefaultGradleLa uncher.java:154) at org.gradle.internal.Factories$1.create(Factories.java:22) at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(Defaul tBuildOperationExecutor.java:90) at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(Defaul tBuildOperationExecutor.java:52) at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(Default GradleLauncher.java:151) at org.gradle.initialization.DefaultGradleLauncher.access$200(DefaultGra dleLauncher.java:32) at org.gradle.initialization.DefaultGradleLauncher$1.create(DefaultGradl eLauncher.java:99) at org.gradle.initialization.DefaultGradleLauncher$1.create(DefaultGradl eLauncher.java:93) at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(Defaul tBuildOperationExecutor.java:90) at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(Defaul tBuildOperationExecutor.java:62) at org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradle Launcher.java:93) at org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLaun cher.java:82) at org.gradle.launcher.exec.InProcessBuildActionExecuter$DefaultBuildCon troller.run(InProcessBuildActionExecuter.java:94) at org.gradle.tooling.internal.provider.ExecuteBuildActionRunner.run(Exe cuteBuildActionRunner.java:28) at org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildA ctionRunner.java:35) at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProce ssBuildActionExecuter.java:43) at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProce ssBuildActionExecuter.java:28) at org.gradle.launcher.exec.ContinuousBuildActionExecuter.execute(Contin uousBuildActionExecuter.java:77) at org.gradle.launcher.exec.ContinuousBuildActionExecuter.execute(Contin uousBuildActionExecuter.java:47) at org.gradle.launcher.exec.DaemonUsageSuggestingBuildActionExecuter.exe cute(DaemonUsageSuggestingBuildActionExecuter.java:51) at org.gradle.launcher.exec.DaemonUsageSuggestingBuildActionExecuter.exe cute(DaemonUsageSuggestingBuildActionExecuter.java:28) at org.gradle.launcher.cli.RunBuildAction.run(RunBuildAction.java:43) at org.gradle.internal.Actions$RunnableActionAdapter.execute(Actions.jav a:170) at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction. execute(CommandLineActionFactory.java:237) at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction. execute(CommandLineActionFactory.java:210) at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRunti meValidationAction.java:35) at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRunti meValidationAction.java:24) at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute( CommandLineActionFactory.java:206) at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute( CommandLineActionFactory.java:169) at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionRep ortingAction.java:33) at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionRep ortingAction.java:22) at org.gradle.launcher.Main.doAction(Main.java:33) at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45) at org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBoots trap.java:54) at org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.j ava:35) at org.gradle.launcher.GradleMain.main(GradleMain.java:23) at org.gradle.wrapper.BootstrapMainStarter.start(BootstrapMainStarter.ja va:30) at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:129) at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:61) Caused by: java.lang.RuntimeException: dagger.internal.codegen.Util$CodeGenerati onIncompleteException: Unknown type returned as . at com.sun.tools.javac.main.Main.compile(Main.java:469) at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:132) at org.gradle.api.internal.tasks.compile.JdkJavaCompiler.execute(JdkJava Compiler.java:45) at org.gradle.api.internal.tasks.compile.JdkJavaCompiler.execute(JdkJava Compiler.java:33) at org.gradle.api.internal.tasks.compile.NormalizingJavaCompiler.delegat eAndHandleErrors(NormalizingJavaCompiler.java:101) at org.gradle.api.internal.tasks.compile.NormalizingJavaCompiler.execute (NormalizingJavaCompiler.java:50) at org.gradle.api.internal.tasks.compile.NormalizingJavaCompiler.execute (NormalizingJavaCompiler.java:36) at org.gradle.api.internal.tasks.compile.CleaningJavaCompilerSupport.exe cute(CleaningJavaCompilerSupport.java:34) at org.gradle.api.internal.tasks.compile.CleaningJavaCompilerSupport.exe cute(CleaningJavaCompilerSupport.java:25) at org.gradle.api.tasks.compile.JavaCompile.performCompilation(JavaCompi le.java:157) at org.gradle.api.tasks.compile.JavaCompile.compile(JavaCompile.java:139 ) at org.gradle.api.tasks.compile.JavaCompile.compile(JavaCompile.java:93)

at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:75) at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskF

actory$IncrementalTaskAction.doExecute(AnnotationProcessingTaskFactory.java:244)

at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskF

actory$StandardTaskAction.execute(AnnotationProcessingTaskFactory.java:220) at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskF actory$IncrementalTaskAction.execute(AnnotationProcessingTaskFactory.java:231) at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskF actory$StandardTaskAction.execute(AnnotationProcessingTaskFactory.java:209) at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.ex ecuteAction(ExecuteActionsTaskExecuter.java:80) at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.ex ecuteActions(ExecuteActionsTaskExecuter.java:61) ... 60 more Caused by: dagger.internal.codegen.Util$CodeGenerationIncompleteException: Unkno wn type returned as . at dagger.internal.codegen.Util$2.visitString(Util.java:164) at dagger.internal.codegen.Util$2.visitString(Util.java:161) at com.sun.tools.javac.code.Attribute$Error.accept(Attribute.java:269) at dagger.internal.codegen.Util$2.visitArray(Util.java:179) at dagger.internal.codegen.Util$2.visitArray(Util.java:161) at com.sun.tools.javac.code.Attribute$Array.accept(Attribute.java:233) at dagger.internal.codegen.Util.getAnnotation(Util.java:205) at dagger.internal.codegen.GraphAnalysisProcessor.collectIncludesRecursi vely(GraphAnalysisProcessor.java:283) at dagger.internal.codegen.GraphAnalysisProcessor.collectIncludesRecursi vely(GraphAnalysisProcessor.java:324) at dagger.internal.codegen.GraphAnalysisProcessor.processCompleteModule( GraphAnalysisProcessor.java:166) at dagger.internal.codegen.GraphAnalysisProcessor.process(GraphAnalysisP rocessor.java:148) at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcess or(JavacProcessingEnvironment.java:793) at com.sun.tools.javac.processing.JavacProcessingEnvironment.access$200( JavacProcessingEnvironment.java:97) at com.sun.tools.javac.processing.JavacProcessingEnvironment$DiscoveredP rocessors$ProcessorStateIterator.runContributingProcs(JavacProcessingEnvironment .java:644) at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(J avacProcessingEnvironment.java:1027) at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessin g(JavacProcessingEnvironment.java:1185) at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler .java:1108) at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:824) at com.sun.tools.javac.main.Main.compile(Main.java:439) ... 78 more

BUILD FAILED
opened by zakiravian 0
Documentation Tip: Search Structurally @Provides
Hello, thanks for dagger, which is great.

A co-worker of mine who was unfamiliar with it was confused all the time from where those @Inject fields come from.

To make his life easier, here is a structural search pattern that people can use, it's quite useful

Action Search Structurally (or Edit > Find > Search Structurally)

Enter the following template

class $Class$ { @Provides( ) $MethodType$ $MethodName$($ParameterType$ $ParameterName$); }

In Edit variables, edit $MethodName$ like this

Also edit $ParameterName$

Now when you serach Search Structurally, you get

Save it as template named Dagger @Provides so you can use it next time from (Copy from existing template)

Hope that helps!
opened by jmfayard 1

Owner

Square

GitHub https://square.github.io/dagger/

Guice (pronounced 'juice') is a lightweight dependency injection framework for Java 6 and above, brought to you by Google.

Guice Latest release: 5.0.1 Documentation: User Guide, 5.0.1 javadocs, Latest javadocs Continuous Integration: Mailing Lists: User Mailing List Licens