Community
Participate
Working Groups
Build 20020820 Setup: Project A contains package fragment p with class K Project B also contains package fragment p Project C in class D references class K (i.e. p.K) When I now search for references to B.p (i.e. the package fragment p in B) it also returns reference to A.p (from C.D) This is also affects the rename refactoring: when renaming B.p it suggests to also rename the p in D resulting in an invalid workspace (because p in A did not change).
oops. was for core.
Package fragment reference is transformed into a package reference internaly. Thus we loose the package fragment root info. Note that the underlying compiler support doesn't know about pkg fragment root, so getting this right in search would require a lot of work.
Worse than the Search (result)is the fact that it breaks refactoring. The resulting code doesn't compile any longer.
We could restrain search to projects referring directly/indirectly onto the root of the target element (if cannot see it on its expanded classpath of candidate, then no point looking into it).
Changed index selector to return indexes of projects or jars that can see the referenced element if any. Also filter working copies that cannot see the referenced element.
*** Bug 30731 has been marked as a duplicate of this bug. ***
Verified.
