Summary: | Refactoring a package does not move the package's directory | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Peter Hack <pahack> |
Component: | Core | Assignee: | Jerome Lanneluc <jerome_lanneluc> |
Status: | VERIFIED FIXED | QA Contact: | |
Severity: | major | ||
Priority: | P2 | CC: | dirk_baeumer |
Version: | 2.0 | ||
Target Milestone: | 2.0.2 | ||
Hardware: | PC | ||
OS: | Windows All | ||
Whiteboard: |
Description
Peter Hack
2002-08-14 20:52:49 EDT
I assume that you executed Refactor->Rename on org.eclipse.foo and specified org.eclipse.bar as the new name. In build 2.0 the corresponding refactoring action calls IPackageFragment.rename (...) to do the actual rename (see RenamePackageChange#doRename()). The JDT/Core code uses Workspace.move(...) to move the resources from the old package to the new package (see JavaModelOperation#moveResources(...)). Nick, two questions: - did you use Refactor->Rename to refactor the package - can you please use the 2.0 build. If you still don't get the corresponding move hook there might be a problem in core resources Philippe, do you have additional comments ? "Nick" should of course read "Peter" <g>. Please also backport a fix in 2.0.1 branch (for forthcoming 2.0.2 rollup). Actually JDT/Core was not using move() for package fragments. Fixed CopyResourceElementsOperation to use move() when possible. However the following cases cannot use move(): 1. If you have a package x.y and you rename it to x.y.z, then the folder x/y cannot be moved to x/y/z (Platform/Core restriction). So in this case, the folder x/y/z is created and the compilation units in x/y are moved to x/y/z. 2. If you have 2 packages x and x.y and you rename x to z, the the folder x cannot be moved to z since we do not want to touch package x.y. So in this case, z is created and the compilation units directly in x are moved to z. Fix backported to 2.0.1 branch. Backporting to 2.0.2 agreed by PMC Verified in 2.1 M1 |