Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 323824

Summary: [search] Script files in a library in one project are not showing up in hierarchy in another project
Product: [WebTools] JSDT Reporter: Chris Jaun <cmjaun>
Component: GeneralAssignee: Chris Jaun <cmjaun>
Status: RESOLVED FIXED QA Contact: Nitin Dahyabhai <thatnitind>
Severity: normal    
Priority: P3 CC: david_williams, thatnitind
Version: 3.2.1Flags: david_williams: pmc_approved+
cmjaun: pmc_approved? (raghunathan.srinivasan)
cmjaun: pmc_approved? (naci.dai)
cmjaun: pmc_approved? (deboer)
cmjaun: pmc_approved? (neil.hauge)
cmjaun: pmc_approved? (kaloyan)
thatnitind: review+
Target Milestone: 3.2.2   
Hardware: PC   
OS: Windows XP   
Whiteboard: PMC_approved
Attachments:
Description Flags
patch none

Description Chris Jaun CLA 2010-08-27 10:02:57 EDT 
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.
Comment 1 Chris Jaun CLA 2010-08-27 10:04:11 EDT 
Created attachment 177615 [details]
patch

Was not accepting the fact that a source folder could be a library in another project.
Comment 2 Chris Jaun CLA 2010-08-31 15:28:15 EDT 
* 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.
Comment 3 David Williams CLA 2010-08-31 21:56:41 EDT 
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,
Comment 4 Chris Jaun CLA 2010-09-01 11:33:46 EDT 
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.
Comment 5 Chris Jaun CLA 2013-12-10 10:25:04 EST 
*** Bug 325147 has been marked as a duplicate of this bug. ***