Community
Participate
Working Groups
Build Identifier: 20100917-0705 I have defined an annotation in source code like: @Target({ElementType.TYPE, ElementType.METHOD}) @Retention(RetentionPolicy.RUNTIME) public @interface MetaCombo { blablabla } I am using that annotation in another project on a property: @MetaCombo(dataSet = PrintingMethodLister.class, properties = {@MetaDisplayProperty(name = "desc")}) @ManyToOne(optional = true, fetch = FetchType.LAZY) @JoinColumn(name = "CAE_ID") public PrintingMethod getPrintingMethod() { blablabla } When I select @MetaCombo in the MetaCombo source file, then do "References > Workspace" it /only/ finds references where the annotation is used in code, for instance it finds: if(an instanceof MetaCombo) { MetaCombo c = (MetaCombo) an; but it does NOT find the annotation on the property. Reproducible: Always
I couldn't reproduce it using a small test case. Can you please provide a minimal, compilable testcase that could show the problem? Thanks.
For some reason a small testcase indeed does not exhibit this problem. I will experiment some more but I dont know what triggers this 8-( It is most definitely wrong somewhere though- it goes wrong in multiple workspaces. And if I do that lookup on the annotation present on the method it does not find itself 8-/ Are there indexes that can be outdated somehow and that I can rebuild?
(In reply to comment #2) > Are there indexes that can be outdated somehow and that I can rebuild? Do you see the problem in a fresh workspace without any changes -- If so, it should not be a problem with the stale indexes.
It also has trouble in refactoring. I refactored (renamed) an annotation and after it was left with 500+ errors where the old name was not changed, sigh. I still cannot reproduce it simply though so I'm just adding this for extra data.
(In reply to comment #4) Is there any thing logged in the .log file kept in <workspace>/.metadata folder?
(In reply to comment #5) > (In reply to comment #4) > Is there any thing logged in the .log file kept in <workspace>/.metadata > folder? Do you see any info in the .log file?
Is there any more data that you could help us with?
(In reply to comment #7) > Is there any more data that you could help us with? I tried this again with Indigo and it still occurs. But I noticed something which may perhaps help: the big workspace this occurs in has multiple projects. When I search on this annotation it always only returns results in the project where the annotation ITSELF is defined in. To make it clearer: the annotation is defined in project "domUI". It is used in project "Database", for instance on class "Invoice". Now if I do a "find references" on the annotation within that class Invoice, and I choose "find references within project" it still only returns occurrences in the domUI project. - even when that is not part of the search scope. So to me this looks like the code does not pass the seach scope properly, somehow. If someone can tell me where this code starts in the Eclipse source code I can check it out and run some debugging by myself. But I know of no other way to help 8-/
(In reply to comment #8) Thanks for some more detailed steps, but I couldn't reproduce with a simple test case. Thanks for the offer for debugging. I will update with detailed steps.
Before debugging, it is worth just getting me the debug output. Here are the instructions for it. Create a file called .options in the eclipse folder with the following lines in it. ###### org.eclipse.jdt.core/debug=true org.eclipse.jdt.core/debug/search=true ###### Then run eclipse as %eclipsec.exe -debug Please give the output of the command. Please also attach the file .metadata/.log located in your workspace.
I am writing this instructions for completeness. You could do this if we couldn't make much from the debug log. Here are some important code points that the code should flow through for all the files/matches. To debug, the entry point for this search is org.eclipse.jdt.core.search.SearchEngine#search() -- the non-deprecated search should be good. Look at the values of pattern and the scope here. Then stop at org.eclipse.jdt.internal.core.search.matching.MatchLocator#locateMatches(SearchDocuments[]). The searchDocuments should show all the files. It may have some files which don't have the references but it should have all the files that has the references. Basically, in this function, the results are filtered and for those which have the files, appropriate model elements are returned. Then it should end up at for all the references eorg.eclipse.jdt.internal.core.search.matching.TypeReferenceLocator#resolveTypeFor(TypeBinding). It should then go to org.eclipse.jdt.internal.core.search.matching.MatchLocator#reportMatching(...). org.eclipse.jdt.internal.core.search.matching.MatchLocator#reportMatch(SearchMatch) should eventually report the match.
Created attachment 201921 [details] Console output after -debug with options from #7 Result of "find references in workspace" - console log
The .log file in the workspace remains empty.
And perhaps for extra info: - the MetaCombo annotation is defined in project "to.etc.domui". - the search was done on an instance present at a property of the "Invoice" class which is present in project "moca.database"
Thanks for the log. Looks like the particular annotation wasn't indexed. Will it be possible for you to give Invoice.java or atleast the exact code snippet that is used in conjuction with the annotation?
Created attachment 201935 [details] Class containing @MetaCombo refs
(In reply to comment #16) > Created attachment 201935 [details] > Class containing @MetaCombo refs Thanks for the ref file, but I am still unable to reproduce:( Does search for refs to MetaDisplayProperty work? Can you also give the definition of both MetaCombo and MetaDisplayProperty?
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
