Enhance the BuildContext with the discovered annotations#676
Enhance the BuildContext with the discovered annotations#676jarthana merged 1 commit intoeclipse-jdt:masterfrom
Conversation
|
@stephan-herrmann or @iloveeclipse can you review this or suggest a reviewer? This would be really helpful for PDE to not scan source files unnecessarily for annotations. |
|
The testfailure seems unrelated? |
Yes. Can you please add some tests using new API? |
|
I have now enhanced |
|
Build has passed now! 🥳 |
|
@iloveeclipse could this be merged or is anything left here? |
|
Someone need to review this PR. I could do it later, this weekend or next week, I'm busy right now with internal HR work and mostly not have access to my workstation. |
|
@iloveeclipse any chance for this PR to be reviewed, or maybe suggest a reviewer for this? |
|
Let's consider this for M1. |
Please let me know if anything has to be done from my side! |
|
I am considering this for merging this week. If anything, we can take up in follow up bugs. Let's see if we can get rid of the jenkins failures. |
9a4be66 to
7f4c05c
Compare
|
I think I found the problem was some refactorings in the meantime and the change of the verions so there was an API error. |
|
Please rebase to get rid of #1150 issue |
|
@iloveeclipse @jarthana this now is rebased and test are passing. |
jarthana
left a comment
There was a problem hiding this comment.
This is just an observation. I see that we have the types already being added to the AbstractImageBuilder.newState.typeLocators. I don't see a direct way to use them, though.
|
Now it fails with a different test. I see it passed locally, but the fact that it is not a test that has failed before and that it is related to the annotations, makes me wonder. |
|
I tried to enhance the assertin failure with some more information. |
|
The full failed exception trace is now shown as |
|
@jarthana I think the problem is the check for empty, because before the code was
I will revert this, rebase (again) and then think it could be merged as is and if someone with deeper knowledge want to optimize it later on? |
Yes, earlier we could easily detect annotations (that don't have have annotations themselves) by just the hasAnnotations flag. Now, it looks like we are going to have a depend on the presence of an empty []. Not a solid design, but I don't see this being fixed without putting the hasAnnotations back in the code.
Please fix this typo: precence => presence and then we are good to go. |
Currently one can only get the information that annotations are present on a file in a BuildContext / CompilationParticipant but sometimes it is much more interesting to know if a specific annotation is present so one don't need to scann files unnecsaryly. This captures the found low-level annotations and adds a new method based on this BuildContext.hasAnnotations(String) so that CompilationParticipant can check fi the file is of any interest for them. Fix eclipse-jdt#674
done! |
…#676) Currently one can only get the information that annotations are present on a file in a BuildContext / CompilationParticipant but sometimes it is much more interesting to know if a specific annotation is present so one don't need to scann files unnecsaryly. This captures the found low-level annotations and adds a new method based on this BuildContext.hasAnnotations(String) so that CompilationParticipant can check fi the file is of any interest for them. Fix eclipse-jdt#674
…#676) Currently one can only get the information that annotations are present on a file in a BuildContext / CompilationParticipant but sometimes it is much more interesting to know if a specific annotation is present so one don't need to scann files unnecsaryly. This captures the found low-level annotations and adds a new method based on this BuildContext.hasAnnotations(String) so that CompilationParticipant can check fi the file is of any interest for them. Fix eclipse-jdt#674
…#676) Currently one can only get the information that annotations are present on a file in a BuildContext / CompilationParticipant but sometimes it is much more interesting to know if a specific annotation is present so one don't need to scann files unnecsaryly. This captures the found low-level annotations and adds a new method based on this BuildContext.hasAnnotations(String) so that CompilationParticipant can check fi the file is of any interest for them. Fix eclipse-jdt#674
What it does
Currently one can only get the information that annotations are present on a file in a
BuildContext/CompilationParticipantbut sometimes it is much more interesting to know if a specific annotation is present so one don't need to scan files unnecessary.This captures the found low-level annotations and adds a new method based on this
BuildContext.hasAnnotations(String)so thatCompilationParticipantcan check if the file is of any interest for them.Fix #674
How to test
CompilationParticipantCompilationParticipant.processAnnotations(BuildContext[])check thatbuildContext.hasAnnotations("...")returns true for you annotation of interest.Author checklist