Bugzilla – Full Text Bug Listing
| Summary: | newTypeHierarchy(IRegion,...) should not be constrained to an IJavaProject | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Markus Keller <markus.kell.r> |
| Component: | Core | Assignee: | Jerome Lanneluc <jerome_lanneluc> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | dirk_baeumer, jerome_lanneluc, philippe_mulet |
| Version: | 3.1 | ||
| Target Milestone: | 3.1 M5 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
Added JavaCore#newTypeHierarchy(IRegion, WorkingCopyOwner, IProgressMonitor) that creates a type hierarchy on a region independantly from a project. Note that old APIs must remain for backward compatibility. Added test TypeHierarchyTests#testRegion4 Verified in I20050214-0927 |
As Dirk has discussed with Philippe and Jerome, we need API to build a supertypes hierarchy on an arbitrary IRegion that crosses project boundaries. This API is required for the new implementation of the RippleMethodFinder. Currently, IJavaProject has methods newTypeHierarchy(IRegion, IProgressMonitor) newTypeHierarchy(IRegion, WorkingCopyOwner, IProgressMonitor) , whose Javadocs promise exactly that. The only sore point is that these methods have to be called on an IJavaProject, and it is not clear to me what the role of the receiver project is. If the methods don't depend on the receiver project, then the methods should be moved to JavaCore. If they do depend, then - that dependency should be explained in the methods' Javadocs, and - we request new methods on JavaCore which build the supertypes hierarchy on types from an arbitrary IRegion.