question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Incremental Annotation Processing doesn't seem to be working when applied via kapt

See original GitHub issue

My team has been reluctant to adopt dagger due to its cost in incremental build times, so until incremental annotation processing was implemented this wasn’t really an option for us.

Now that this was implemented here, I decided to take a look at it and built the most recent version of master locally, and imported it into my team’s project, and enabled the compile flag. I’m not even using dagger for anything, this is just enabling dagger to see how expensive it is before I add anything for dagger to do (I guess it’s scanning the codebase for dagger annotations).

I found incremental ABI changes took the same amount of time with and without the compiler flag (4-6 seconds) per module I applied the dagger annotation processor in, so this is about a 50% increase in our incremental build times just to apply dagger to begin with. I find this surprising, shouldn’t dagger only need to re-look at the file I changed? Why is it doing (what appears to be) the same amount of work compared to incremental processing being disabled?

I guess it’s possible I’m doing something wrong, so I’m applying dagger via kapt like this in each of my module’s build.gradle files:

kapt "com.google.dagger:dagger-compiler:LOCAL-SNAPSHOT"

And enabling the flag for incremental processing like this in my project level build.gradle file:

subprojects {
    tasks.withType(JavaCompile) {
        options.compilerArgs << "-Adagger.gradle.incremental"
    }
}

The kaptGenerateStubsDebugKotlin task takes about 1 second, while the kaptDebugKotlin task takes about 4 seconds. This is pretty consistent, I did about a dozen trials of with and without the compiler flag and got pretty consistent results.

So I guess either there’s a bug where the compiler flag doesn’t work with kapt, I’m doing something wrong, or I’m just expecting too much out of the incremental processing.

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Comments:7

github_iconTop GitHub Comments

5reactions
jd-alexandercommented, Mar 20, 2019
4reactions
cypressiouscommented, Oct 22, 2018
Read more comments on GitHub >

github_iconTop Results From Across the Web

How to get rid of Incremental annotation processing requested ...
Enable Kapt Incremental annotation processing requeste ... I'm using AndroidX, but It guess it's the same for android.arch.lifecycle .
Read more >
Kapt does not run annotation processing when sources change.
I've noticed you seem to be using annotation processor that outputs kt files. Are those generated using Filer or using java.io ?
Read more >
Using kapt | Kotlin
kapt supports incremental annotation processing that is enabled by default. Currently, annotation processing can be incremental only if all ...
Read more >
Support Gradle incremental annotation processing [112110217]
w: [kapt] Incremental annotation processing requested, but support is disabled because the following processors are not incremental: androidx.room.
Read more >
Incremental annotation processors compilation for Kotlin (KAPT)
Incremental annotation processors compilation is now available for Kotlin! Learn how to use the newest Kotlin plugin version to enable it.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found