Community
Participate
Working Groups
Project A - script folder --file with ClassA defined Project B - file with sub-class of ClassA defined - references script folder in Project A as a library folder Project C - file with sub-class of ClassA defined - references Project A directly If I show type hierarchy on ClassA I should see both sub-classes listed in the view.
Created attachment 177615 [details] patch Was not accepting the fact that a source folder could be a library in another project.
* Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. The hierarchy view is broken when types and their subtypes are declared across projects. Any tooling which depends on building a type hierarchy, such as determining super type methods in content assist is broken. * Is there a work-around? If so, why do you believe the work-around is insufficient? The only workaround would be to not use separate projects, but this seems to be a common setup for users. * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? It was manually tested by creating super and sub type relationships across projects and verifying the the hierarchies were built correct and displayed in the view. * Give a brief technical overview. Who has reviewed this fix? Nitin reviewed the fix. Code was added to search include paths when a PackageFragementRoot was discovered in a referenced library location. All previous functionality remains, we just added this additional check. This is needed because in JSDT, unlike JDT, libraries can be stored as source files under PackageFragmentRoots in the workspace. * What is the risk associated with this fix? Low. No existing main line functionality was changed, we just added an additional check for library references.
I think this is an important fix, but will ask if "degenerate" cases have been accounted for ... that is, if there would be cases of very deep (or even circular?) references that would have performance implications? I know very little about this construct "PackageFragmentRoots" so maybe it's clear to others ... but thought I'd ask. Thanks,
Checked into 3.2.2 and HEAD. This should not cause any performance issues. The pattern of checking include paths like this is very common in JSDT. This particular case had never been updated from the JDT days to work with libraries in source.
*** Bug 325147 has been marked as a duplicate of this bug. ***
