Bug 137401 - [rename] rename type without renaming the CU
Summary: [rename] rename type without renaming the CU
Status: ASSIGNED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.2   Edit
Hardware: Macintosh Mac OS X - Carbon (unsup.)
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Markus Keller CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-04-18 19:26 EDT by Gordon Henriksen CLA
Modified: 2009-05-06 06:54 EDT (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Gordon Henriksen CLA 2006-04-18 19:26:55 EDT 
To preserve Subversion revision history when renaming a class (class Foo to class Bar), I used svn mv to move the source file (svn mv Foo.java Bar.java), then went back to Eclipse and decided to try the rename refactoring to fix my references to the already-renamed file (which now had an error). The refactoring failed, complaining that the compilation unit (Bar.java) already existed.
Comment 1 Gordon Henriksen CLA 2006-04-18 19:27:52 EDT 
Eclipse SDK

Version: 3.2.0
Build id: I20060413-1718

Darwin Gordons-MacBook-Pro.local 8.6.1 Darwin Kernel Version 8.6.1: Tue Mar  7 16:55:45 PST 2006; root:xnu-792.9.22.obj~1/RELEASE_I386 i386 i386
Comment 2 Frederic Fusier CLA 2006-04-19 02:26:41 EDT 
Have you done a refresh of your workspace before the rename refactoring?
Comment 3 Gordon Henriksen CLA 2006-04-19 03:45:13 EDT 
Yes.
Comment 4 Frederic Fusier CLA 2006-04-19 03:56:38 EDT 
So, I guess your workspace looks as follows:

Project
  + src
    + Bar.java
      + public class Foo {
        ...
        }

If this is correct, on which java element did you try to perform the rename:
compilation unit 'Bar.java' or type 'Foo' ?

If this is not correct, please provide more details on your test case and how you try to perform the rename, thanks
Comment 5 Gordon Henriksen CLA 2006-04-19 04:15:18 EDT 
I was performing the refactor on the type.

1. Take any class file Foo.java. External to Eclipse, move it to Foo2.java.
2. Return to Eclipse. If auto-refresh is not on, refresh now.
3. Open Foo2.java, which contains class Foo, and which is in error (wrong compilation unit name…).
4. Select the type name (Foo), and perform the Rename refactor to 'Foo2'.
5. The refactor fails with the error ‘Compilation unit "Foo2.java" already exists.’
Comment 6 Frederic Fusier CLA 2006-04-19 06:01:03 EDT 
Move to JDT/UI for comments as this check is done there.
Comment 7 Martin Aeschlimann CLA 2006-04-19 09:54:18 EDT 
We only support refactorings on compiling code. I assume that was not the case here, right?
Comment 8 Gordon Henriksen CLA 2006-04-19 12:11:51 EDT 
Yes, that's correct.


The aggravating use case is revision history through a rename with Subversion, if it would be better to recategorize or file this as a feature. The workaround is circuitous at best:

1. Use 'svn mv Foo.java Foo2.java', since svn mv wants to operate on unmodified files.
2. mv Foo2.java Foo.java
3. Refactor with Eclipse (including a 'mv Foo.java Foo2.java')…
Comment 9 Martin Aeschlimann CLA 2006-04-20 08:18:39 EDT 
I see. Markus, maybe you can investigate in 3.3 if this is easy doable on our side: Rename a class without renaming the CU.
Comment 10 Gunnar Wagenknecht CLA 2006-09-06 05:28:06 EDT 
(In reply to comment #8)
> The aggravating use case is revision history through a rename with Subversion,
> if it would be better to recategorize or file this as a feature. The workaround
> is circuitous at best:

FYI, there are two Subversion plug-ins for Eclipse. Both integrate well with refactoring so that the revision history is preserved when you rename a compilation unit through the Eclipse refactoring actions.
Comment 11 Eclipse Webmaster CLA 2007-07-29 09:19:32 EDT 
Changing OS from Mac OS to Mac OS X as per bug 185991