You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 26, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Feb 26, 2023. It is now read-only.
Improve handling of ErrorTypes through multiple annotation processing rounds #25
We currently don't take advantage of the multiple rounds of annotation processing. This is because we don't add any annotation to the generated code, so it doesn't need to be processed again.
When we do a clean build, we are in a situation where some generated artifacts are used in the code, but not available yet since they've just been cleaned. This leads to hard times trying the determine the types of some elements. The type of those elements is described as an "ErrorType".
The current decision when we encounter such elements is to treat them as "correct" elements and validate them without checkout them any more. We trust the developer. It works quite well, but it's not really future proof.
A solution could be to use multiple rounds for that, if possible. We could collect the elements that cannot be validated on a round because they depend on a generated item, then let the round generate the missing code, them do an extra round and treat the previously received elements.
That's not gonna be easy because our model doesn't work that way, so we have to think it through.
Activity
pyricau commentedon Oct 18, 2012
We fixed this problem as of 2.7, users are not allowed to extend generated classes any more, and we collect all annotations from parent classes.