Summary: | [search] does not find method references in anonymous class of imported jarred plugin | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Markus Keller <markus.kell.r> |
Component: | Core | Assignee: | Frederic Fusier <frederic_fusier> |
Status: | VERIFIED FIXED | QA Contact: | |
Severity: | major | ||
Priority: | P3 | CC: | jerome_lanneluc, philippe_mulet |
Version: | 3.1 | ||
Target Milestone: | 3.1 M6 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Markus Keller
2005-03-31 11:56:15 EST
Search fails as this is the binary file which is processed instead of associated source file. I continue to investigate... Jerome, With M5, while getting Class File reader in MatchLocator, the root was a JarPackageFragmentRoot (jface.jar [in org.eclipse.jface]) which was clearly identified as an archive (root.isArchive() returns true). However, with jarred plugin, the root is now a "simple" PackageFragmentRoot (<project root> [in org.eclipse.jface]) which is not considered as an archive. As root.isArchive() returns false on this root, we fail to look in zip file and so we're missing attached source... Is there anything simple to do to avoid this which could be put in M6? It seems to come from MatchLocator.classFileReader(IType) which does not use full path when root is not an archive. Following lines: if (!root.isArchive()) return ClassFileReader.read(type.getPath().toOSString()); should have been written: if (!root.isArchive()) return ClassFileReader.read(type.getResource().getLocation().toOSString()); I've run all JDT/Core tests with this fix and everything is green... I'll run also JDT/UI tests in case of and add a specific test for this bug. Then I'll release the change for M6. Fixed. Described code change has been released in HEAD. All JDT/UI tests (version v20050331-1200) are green. Test case added in JavaSearchBugsTests. Verified in I20050401-1205 |