Skip to content
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

Gradle's incremental build feature breaks annotation processing #298

Closed
sockeqwe opened this issue Jan 30, 2016 · 13 comments
Closed

Gradle's incremental build feature breaks annotation processing #298

sockeqwe opened this issue Jan 30, 2016 · 13 comments

Comments

@sockeqwe
Copy link

@sockeqwe sockeqwe commented Jan 30, 2016

Gradle has this incremental build feature to speed up build times (especially useful on android). The problem with incremental builds is that the annotation processor will only run for those classes who has been changed and not for the whole project / source files.

In other words:
env.getElementsAnnotatedWith(...) only returns annotated classes that has been changed since previous incremental build. This means that the whole project can't be evaluated and components can't be generated.

I know it's not your fault! I think that there isn't much that you can do. The only thing that comes to my mind is to add some reflection code to glue all together at runtime, but who really wants that ...

I just have created this issue for others (mainly android developers) who struggle with this kind of issue as well. In android you can disable this incremental build feature as follows:

dexOptions {
    incremental false
}
@ronshapiro
Copy link

@ronshapiro ronshapiro commented Feb 3, 2016

Even if you tried the reflection glue (and I did on a side project last week), you will have issues if you change any code that should cause dagger code to generate different output (but not the component itself). It would be great to get someone that's familiar with the incremental compilation step, but as you said, I don't know (at least with my current set of knowledge about this) what we can do, and ideally this is something that could be solved at the build level so that every annotation processor would get this support.

Loading

@sockeqwe
Copy link
Author

@sockeqwe sockeqwe commented Feb 3, 2016

The best way would definitely be scanning the whole project again on incremental builds. As far as I know annotation processing can also scan .class files (RetentionPolicy.RUNTIME), but you have to add them manually to javac when compiling. I have never done that, but it should work. So I think gradle incremental build have to add all other already compiled .class files to javac when compiling the incremental build ...

Loading

@mannodermaus
Copy link

@mannodermaus mannodermaus commented Feb 4, 2016

For me, Hannes' suggestion to disable incremental dex didn't resolve the issue, which is why I had to disable incremental builds a little higher up the compilation chain, as suggested by this guy.

Running Gradle with the following command line option caused Dagger's annotation processor to work properly again:

-Pandroid.incrementalJavaCompile=false

Loading

@ZacSweers
Copy link

@ZacSweers ZacSweers commented Feb 4, 2016

@aurae that's what Tor Norbye suggested to me as well and has worked for me. He said they're considering controlling the incremental flag for recognized processors in the future.

Loading

@gk5885
Copy link

@gk5885 gk5885 commented Feb 4, 2016

I just talked with Tor and the next beta is going to make sure that incremental compilation is turned off for project that use Dagger, so it should at least be better in Android Studio. We're also going to raise the issue with the Gradle folks and see what they have to say.

Loading

@arriolac
Copy link

@arriolac arriolac commented Feb 5, 2016

@gk5885 Shouldn't the solution apply to all projects using annotation processing? Or is this only a dagger-specific problem?

Loading

@tbroyer
Copy link

@tbroyer tbroyer commented Feb 5, 2016

It's not specific to Dagger, but many annotation processors are much simpler, and I think it could work with 1:1 mappings between input and output classes.
Anyway, @gk5885, if you have a link to a Gradle issue please add it here. I believe this problem has been solved in Pants where they (try to) map inputs to outputs and persist this mapping for next rounds.

Loading

@gk5885
Copy link

@gk5885 gk5885 commented Feb 5, 2016

@arriolac, I believe that they selected some list of annotation processors that they knew to have problems. I don't have any details, but I know that it was addressed for Dagger and some others.

@tbroyer Some people from the Android tools side of things are going to discuss it in their regular sync with the Gradle people. I don't have any details, but they're going to report back when they talk it over.

Loading

@edisonw
Copy link

@edisonw edisonw commented Feb 5, 2016

This is not a dagger-specific problem, it affects all annotation processors that uses getElementsAnnotatedWith(), some are fixable and some are not, for example, I had to do the following for an example project that I maintain:

  1. Fixable without interface changes: edisonw/PennStation@c32b43c
  2. Needs Refactoring: edisonw/PennStation@c1fd069

@gk5885 So this is fixable on the annotation processor side but may have to rethink some use cases.

I think turning it off for all annotation processors is not the right solution, maybe there needs a way for the annotation processors to declare themselves to require the knowledge of all existing files. apt plugin does support variables.

Loading

@cesar1000
Copy link

@cesar1000 cesar1000 commented Nov 10, 2016

Any updates on this? It doesn't look like Android Studio or Gradle are modifying their behavior when dagger is used. I am disabling incremental compilation explicitly in projects that use Dagger, but it would be nice if this would happen automatically.

Loading

@ronshapiro
Copy link

@ronshapiro ronshapiro commented Nov 10, 2016

I would file those issues with the tools issue trackers, not with dagger. Not much we can do on that end.

Loading

@cesar1000
Copy link

@cesar1000 cesar1000 commented Nov 10, 2016

Sure - I asked because of @gk5885's comment from February 4th that mentioned that Android Studio would fix in an upcoming beta. Recent changes to gradle seem to have make it worse, but I only have anecdotal evidence.

Loading

@ronshapiro
Copy link

@ronshapiro ronshapiro commented May 4, 2017

The sense that I get is that http://tools.android.com/tech-docs/new-build-system/2-5-alpha-gradle-plugin will be addressing this. Either way, there is little that Dagger can do here

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
9 participants