Community
Participate
Working Groups
Hi, we have encountered some severe bug in the refactor/rename feature of the JDT in the 30M6 that we have been using intensively since its realease. We have been able to create a simple project where the issues can be reproduced in our environment on two different installation sof 30M6 ()one in WXP, the other in W2K). The setup : a new project with two source trees, tow java suorce, and one xml file with a references to the fully qualified names of instances in the smoe elements. 1st bug : We try refactor/rename on the src/org/test/Reference.java the m_foo member of the tst/org/test/Test.java. The preview, and the refactor will happen in Test.java but WILL NOT UPDATE the m_foo reference in Reference.java. 2nd bug : We try to rename Test.java. Despite we asked for a lookup for fully qualified names everywhere, no proposition to update the xml file is made. 3rd bug : Similar to bug1. We try refactor/rename on the src/org/test/Test.java the m_foo member. The preview, and the refactor will happen only in Test.java but WILL NOT UPDATE the m_foo reference in Reference.java. The attached sample project contanis all the code. We have also tried to do the same things on a brand new Workspace. The bugs behaves exactly the same. We use the 3.0M6 millestone, vanilla. Cheers.
Created attachment 7663 [details] Sample project to reproduce the bug.
We made an additional test to make sure we were correct. We installed a brand new eclipse vanilla 30M6 SDK in a new directory, then created a brand new workspace. The behavior is the same...
We did not find any easy workaround, but at least the places where the renaming did not happen show up as errors markers in the problem view, except for non java files.
please leave assigning priority and target milestone to committers. submitters should only use the severity field, voting and rhetoric to state their perceived importance of the problem.
Sorry for that. My mistake not to check the posting guidelines first... Cheers Philippe
Created attachment 7696 [details] An update to the test project. The xml file did not contain the member reference.
Just double checking the bugs: 1st bug : We try refactor/rename on the src/org/test/Reference.java the m_foo member of the tst/org/test/Test.java. The preview, and the refactor will happen in Test.java but WILL NOT UPDATE the m_foo reference in Reference.java, and in test.xml. 2nd bug : >> I WAS NOT ABLE TO REPRODUCE THIS BUG.We try to rename Test.java. Despite we asked for a lookup for fully qualified names everywhere, no proposition to update the xml file is made. 3rd bug : Similar to bug1. We try refactor/rename on the src/org/test/Test.java the m_foo member. The preview, and the refactor will happen only in Test.java but WILL NOT UPDATE the m_foo reference in Reference.java and in test.xml. In any case (1 and 3), if Test.java and Reference.java, the java renaming of the member works fine, but the xml file is always ignored. SO it seems the issue is with using various source folders, which is quite common, ie one for main sources, one for tests sources.
Created attachment 7772 [details] Patch that fixes the problem The problem is that if a member is package visible we only searched inside the package for references. But given the fact that there can be multiple packages with the same name in different source folders this is a wrong optimazation. Updating the XML file worked fine for me using I20040210. Are there special steps ?
Reviewed and released Dirk's patch from comment 8. Will go into 3.0 M7.
Great patch. On the topic on xml updates, when you do a refactor/rename on the m_foo memeber, no option is offered to "Update fully qualified name in non java files" As a result the renaming of the member can never be propagated to the xml file. Actually renaming members never has that option available whatever the modifer (public, private, default, protected) you use. Therefore there seems to be an assumption that a member fully qualified name is NEVER used in an external file... While I would say this may not be good programmnig style, there is no reason why refactoring should just ignore that. As far as renaming of classes, not members, it works fine and is propagated to the xml file.
Renaming members in java files from different source folders is fixed in 200402120010. Philippe, could you please open a new bug report against JDT UI for your comment 10? That bug (no support for updating names of java members in non-java files) is another topic, which should have its own PR.
Done see bug #51898 https://bugs.eclipse.org/bugs/show_bug.cgi?id=51898 Cheers Philippe
