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 incremental - the final problem #74

Open
igor-makarov opened this issue Nov 26, 2022 · 4 comments
Open

Gradle incremental - the final problem #74

igor-makarov opened this issue Nov 26, 2022 · 4 comments

Comments

@igor-makarov
Copy link
Contributor

I've created a branch where I build the project with Gradle and included a demo project.

Link: link

Seems like there are 2 interrelated problems:

  1. The wildcard * match on the annotation type causes the build system to match annotations that are incompatible with an aggregate processor type.
  2. Narrowing down the list to just the two annotations causes subsequent incremental builds to delete the index files. This might be related to one of the annotations being a meta-annotation (inheritance?).

There could be two solutions in theory:

  1. Figure out the incremental build troubles and the non-wildcard match (hard).
  2. Rewrite the index format to enable the processor to run in isolation (each input produces an independent output) this would avoid problem 1, I think.

To reproduce, run the build of the demo project:

./gradlew :examples:gradle-build:jar --info

Then, modify one of the demo project files and run again.

If you run with the wildcard as is, you will get the following message:

Full recompilation is required because '@AllArgsConstructor' has source retention. Aggregating annotation processors require class or runtime retention.

This is because the wildcard matches a Lombok annotation that has the wrong retention attribute.

If you run it with the list narrowed down, the generated indices can be incomplete or missing, depending on the files modified. I've tried to debug it and it seems that this is due to the logic in ClassIndexProcessor#process making some assumptions about the root object. The other types are seem accessible but I don't understand the logic enough to rewrite it.

Hope this helps debugging.

@igor-makarov
Copy link
Contributor Author

@sentinelt this is my best attempt at a repro, hope it helps!

@igor-makarov
Copy link
Contributor Author

@sentinelt
Update: I've managed to figure out the fix but it only works on Java 9 and up because of a new method.

Please let me know if you can find a way to make it work with Java 8 since that's what the project I'm working on is using.

Important note: I've added @Inherited to the @IndexSubclasses annotation, otherwise the subclasses did not get picked up in an incremental build.

@igor-makarov
Copy link
Contributor Author

@sentinelt Update - seems like it might be relatively easy to change the annotation processor to be isolating - which means generating a single file for each discovered element.

The problem with this approach is that it makes the class loader incompatible with the ClassLoader format.

@albertvaka
Copy link

What's the status of this issue? Is there something that can be done?

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

No branches or pull requests

2 participants