Community
Participate
Working Groups
When refactoring a package (ex. refactoring a package from 'org.eclipse.foo' to 'org.eclipse.bar' from the Packages view) does not appear to use the Eclipse 'move' operation to move 'org\eclipse\foo' to 'org\eclipse\bar'. Instead, it appears as though the 'org\eclipse\foo' directory is deleted and the 'org\eclipse\bar' directory is create new. Then the refactored in- memory .java files are written out in the new location. This causes a *significant* problem for users of version-control systems. Moving the directory to the new name allows the Team Provider to make sure the version history of everything in the package follows to the new location. By implementing the operation as described in the first paragraph, the version history association is lost. Note that this was observed with GM1. I have not yet tested GM6.
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
