Dagger2 annotation processor is not working

Question

I try to use Dagger2 in my Android project; When I use apt, every things is right.But apt is not supported in AndroidStudio 3.0, so I use annotation processor.But no Dagger2 code created after I click "Make Project"; And I'm sure the annotetion processing is enable in AndroidStudio,because the Butterknife annotation processor is all right. the follow is the build.gradle:

dependencies {
    annotationProcessor 'com.google.dagger:dagger-android-processor:2.13'
    compile 'com.google.dagger:dagger-android:2.13'
    compile 'com.google.dagger:dagger-android-support:2.13'
    compile 'com.jakewharton:butterknife:8.6.0'
    annotationProcessor 'com.jakewharton:butterknife-compiler:8.6.0'
}

Answer 1

use this in android studio 3.0 version

implementation 'com.google.dagger:dagger:2.9'
annotationProcessor 'com.google.dagger:dagger-compiler:2.9'

Answer 2

these are the dependences for dagger2 and butter in andriod studio 3.0

  //ButterKniffe
compile "com.jakewharton:butterknife:8.8.1"
kapt "com.jakewharton:butterknife-compiler:8.8.1"

//dagger
compile "com.google.dagger:dagger:$dagger_version"
kapt "com.google.dagger:dagger-compiler:$dagger_version"

Answer 3

It is one of the breaking changes coming with gradle:3.0 that Google announced at IO17 gradle:3.0

the compile configuration is now deprecated and should be replaced by implementation or api From the gradle docs :

Dependencies appearing in the api configurations will be transitively exposed to consumers of the library, and as such will appear on the compile classpath of consumers.

Dependencies found in the implementation configuration will, on the other hand, not be exposed to consumers, and therefore not leak into the consumers' compile classpath. This comes with several benefits:

• List item dependencies do not leak into the compile classpath of consumers anymore, so you will never accidentally depend on a transitive dependency
• faster compilation thanks to reduced classpath size
• less recompilations when implementation dependencies change: consumers would not need to be recompiled
• cleaner publishing: when used in conjunction with the new maven-publish plugin, Java libraries produce POM files that distinguish exactly between what is required to compile against the library and what is required to use the library at runtime (in other words, don't mix what is needed to compile the library itself and what is needed to compile against the library).

The compile configuration still exists but should not be used as it will not offer the guarantees that the api and implementation configurations provide.