Skip to content

Enhance the BuildContext with the discovered annotations#676

Merged
jarthana merged 1 commit intoeclipse-jdt:masterfrom
laeubi:issue_674
Jun 27, 2023
Merged

Enhance the BuildContext with the discovered annotations#676
jarthana merged 1 commit intoeclipse-jdt:masterfrom
laeubi:issue_674

Conversation

@laeubi
Copy link
Copy Markdown
Contributor

@laeubi laeubi commented Jan 31, 2023

What it does

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 scan files unnecessary.

This captures the found low-level annotations and adds a new method based on this BuildContext.hasAnnotations(String) so that CompilationParticipant can check if the file is of any interest for them.

Fix #674

How to test

  • Have a CompilationParticipant
  • Have a project with a source file that contains an specific annotation and one without but containing another
  • in the method CompilationParticipant.processAnnotations(BuildContext[]) check that buildContext.hasAnnotations("...") returns true for you annotation of interest.

Author checklist

@laeubi
Copy link
Copy Markdown
Contributor Author

laeubi commented Jan 31, 2023

@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.

@laeubi
Copy link
Copy Markdown
Contributor Author

laeubi commented Jan 31, 2023

The testfailure seems unrelated?

@iloveeclipse
Copy link
Copy Markdown
Member

The testfailure seems unrelated?

Yes. Can you please add some tests using new API?

@laeubi
Copy link
Copy Markdown
Contributor Author

laeubi commented Jan 31, 2023

I have now enhanced ParticipantBuildTests with a new testcase.

@laeubi
Copy link
Copy Markdown
Contributor Author

laeubi commented Jan 31, 2023

Build has passed now! 🥳

@laeubi
Copy link
Copy Markdown
Contributor Author

laeubi commented Feb 1, 2023

@iloveeclipse could this be merged or is anything left here?

@iloveeclipse
Copy link
Copy Markdown
Member

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.

@laeubi
Copy link
Copy Markdown
Contributor Author

laeubi commented Mar 27, 2023

@iloveeclipse any chance for this PR to be reviewed, or maybe suggest a reviewer for this?

@jarthana jarthana added this to the 4.29 M1 milestone May 31, 2023
@jarthana
Copy link
Copy Markdown
Member

jarthana commented Jun 1, 2023

Let's consider this for M1.

@laeubi
Copy link
Copy Markdown
Contributor Author

laeubi commented Jun 11, 2023

Let's consider this for M1.

Please let me know if anything has to be done from my side!

@jarthana
Copy link
Copy Markdown
Member

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.

@laeubi laeubi force-pushed the issue_674 branch 2 times, most recently from 9a4be66 to 7f4c05c Compare June 15, 2023 13:12
@laeubi
Copy link
Copy Markdown
Contributor Author

laeubi commented Jun 15, 2023

I think I found the problem was some refactorings in the meantime and the change of the verions so there was an API error.

@laeubi
Copy link
Copy Markdown
Contributor Author

laeubi commented Jun 19, 2023

@jarthana the testfailure seems unrelated as it can be seen in other PRs as well e.g. here: #1155

@iloveeclipse
Copy link
Copy Markdown
Member

Please rebase to get rid of #1150 issue

@laeubi
Copy link
Copy Markdown
Contributor Author

laeubi commented Jun 20, 2023

@iloveeclipse @jarthana this now is rebased and test are passing.

Copy link
Copy Markdown
Member

@jarthana jarthana left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@jarthana
Copy link
Copy Markdown
Member

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.

@laeubi
Copy link
Copy Markdown
Contributor Author

laeubi commented Jun 22, 2023

I tried to enhance the assertin failure with some more information.

@laeubi
Copy link
Copy Markdown
Contributor Author

laeubi commented Jun 26, 2023

The full failed exception trace is now shown as

junit.framework.AssertionFailedError
	at junit.framework.Assert.fail(Assert.java:55)
	at junit.framework.Assert.assertTrue(Assert.java:22)
	at junit.framework.Assert.assertNotNull(Assert.java:256)
	at junit.framework.Assert.assertNotNull(Assert.java:248)
	at junit.framework.TestCase.assertNotNull(TestCase.java:391)
	at org.eclipse.jdt.apt.tests.MirrorDeclarationTests$PackageInfoProc._process(MirrorDeclarationTests.java:343)
	at org.eclipse.jdt.apt.tests.annotations.generic.AbstractGenericProcessor.process(AbstractGenericProcessor.java:43)
	at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.dispatchToFileBasedProcessor(APTDispatchRunnable.java:668)
	at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.runAPTInFileBasedMode(APTDispatchRunnable.java:357)
	at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.build(APTDispatchRunnable.java:695)
	at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable$1.run(APTDispatchRunnable.java:285)
	at org.eclipse.jdt.apt.core.internal.env.BuildEnv$CallbackRequestor.acceptBinding(BuildEnv.java:631)

@laeubi
Copy link
Copy Markdown
Contributor Author

laeubi commented Jun 26, 2023

@jarthana I think the problem is the check for empty, because before the code was

if (result.hasAnnotations && this.filesWithAnnotations != null)

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?

@jarthana
Copy link
Copy Markdown
Member

@jarthana I think the problem is the check for empty, because before the code was

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.

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?

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
@laeubi
Copy link
Copy Markdown
Contributor Author

laeubi commented Jun 26, 2023

Please fix this typo: precence => presence and then we are good to go.

done!

@jarthana jarthana merged commit 8d512be into eclipse-jdt:master Jun 27, 2023
jarthana pushed a commit to jarthana/eclipse.jdt.core that referenced this pull request Jun 27, 2023
…#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
mpalat pushed a commit to mpalat/eclipse.jdt.core that referenced this pull request Jul 6, 2023
…#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
robstryker pushed a commit to robstryker/eclipse.jdt.core that referenced this pull request Jul 18, 2024
…#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
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

Successfully merging this pull request may close these issues.

Enhance the BuildContext with the discovered annotations

3 participants