Community
Participate
Working Groups
Build Identifier: I20110613-1736 The opened Java-Editor shows reproducable under some circumstances the (wrong) error message "The type .. cannot be resolved. It is indirectly referenced from required .class files." However, the Package-Explorer does not show this error. The error is only displayed in the Editor. If the error happens the org.eclipse.jdt.core.dom.ASTParser is not able to parse this java file (which is called by a plugin of mine). I found no workaround for this but to refactor some classes not to be inner classes any more, but this is not really a good workaround. Reproducible: Always Steps to Reproduce: The error is reproduceable as follows: - Create a class A with a static inner Class I in the sourcefolder "src" with outputfolder "bin". - Create a class B beeing a subclass of I in the same project in another sourcefolder "src2". Let the outputfolder of "src2" be "bin2". - Create a class C beeing a subclass of B in the first source folder "src". - Now change the project settings by removing the sourcefolder "src2" and instead add the "bin2" folder to the libraries. By this the class B is now only available as a binary class file. - Open the Editor for the class C and find the error message describe above. The same problem arises reproducably, if the the class file of B is not in a classfolder but in a jar. There is no problem, if I is not an inner class but a normal class.
I'll take a look.
This was broken also in 3.6.
(In reply to comment #0) > I found no workaround for this but to refactor some classes not to be inner > classes any more, but this is not really a good workaround. This is not a workaround. The problem here is that A is still seen as a source type where B is seen as a binary type. So A$I is searched into a source fragment root as source and not as a binary type. I'll provide a patch soon that will need to be intensively tested.
Created attachment 203069 [details] Patch v1 Under test.
Created attachment 203078 [details] Patch v2 The previous patch would return duplicated types.
Srikanth, please review. This is a case that I believe never worked. Retrieve from a source package fragment a type that is defined inside a binary type (p/A$I in this case).
Released for 3.8M3.
Verified for 3.8 M3 using build id: N20111022-2000 Patch looks good. (could be simplified a bit, but I'll leave it as it is)
If at all possible, could this patch be moved up to the 3.7 Maintenance Branch? We're currently running into this problem with some of our users, and it would be great to see a fix before the 3.8 release.
(In reply to comment #9) > If at all possible, could this patch be moved up to the 3.7 Maintenance Branch? > We're currently running into this problem with some of our users, and it would > be great to see a fix before the 3.8 release. Ayush, Along with the other fixes you are backporting, could you please include this one also please. TIA.
Released in 3-7 maintenance branch via commit 9ae69253a6820a853326ea257bd70fb5b0aab8f4
Verified for 3.7.2RC2 using build M20120118-0800
