Bugzilla – Full Text Bug Listing
| Summary: | [CommonNavigator] JDT actions appearing on resources not related to Java | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Dusko <dmisic> | ||||
| Component: | UI | Assignee: | Michael D. Elder <mdelder> | ||||
| Status: | RESOLVED DUPLICATE | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | bokowski, dleroux, markus.kell.r, mbarkhou, mbologa, Mike_Wilson, mutdosch, philippe_mulet | ||||
| Version: | 3.2 | ||||||
| Target Milestone: | 3.3 M7 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | 157314 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
|
Description
Dusko
Just my 2 cents: if the file is e.g. a *.properties file in a Java package, then the user could as well expect a JDT-oriented move, offering packages, rather than folders as targets. But I agree that this doesn't apply for Move of files from non-Java projects, and for CCP and Rename. I don't mind having JDT move refactoring on *.properties file in a Java package. But I should not get it if the *.properties file is not in a Java package, even if it is in a Java project. That project might have other natures as well. However, the main concern here is really the files that are completely unrelated to Java, regardless of their location. Currently the JDT actions appear on all resources. In our case it is really bad; if the user picks the wrong refactoring action they can severely corrupt their files. Not to mention the look of the UI when 2 or more actions with the same name show up. The JDT refactor actions show up on files, folders, and Java elements in any project that is a Java project. This is consistent with the behavior of the Package Explorer. Rename/Move for any file-based resource should be roughly the same; what are the details of your scenario? Is this a case of multiple EMF-based model files and fixing up the interdependencies among them? Why would not using the Refactor participants available as part of the JDT actions? Taking away the JDT actions for files and folders would leave you with the basic resource Move/Rename which are less sophisticated, and likely to exhibit the same issues you describe. And taking away all move/rename capability so that a downstream component may contribute their own is not an option. In general, I'd expect users to anticipate the same actions as those available on the Package Explorer, and there have been defects opened in the past for any inconsistencies between the menus. Can you describe what it is you're reallying trying to solve? If it is resolving inter-dependencies between files, then I would suggest using the Refactor Participant support. I haven't had a chance to test this with RC3 yet (should be able to do that tomorrow or the day after), all my comments are based on RC2. Currently JDT refactoring actions appear regardless of the project nature. The projects that we have are not Java projects, yet the JDT refactoring actions are there. I would argue that, at the very least, they should not appear on non-Java resources in non-Java projects. Now, if I have a project that has both Java and C++ stuff, does this mean that I should get JDT refactoring wizards on my C++ classes? I don't think it is right, we should get those wizards only for the resources they really now how to handle. I can imagine people working with C++ and getting Java wizards will not really like it. You're right about the nature of our resources. Those are multiple model files (EMF based) that can reference each other and refactoring is supposed to fix those references. I agree that we should register participants to make sure regardless which wizard is invoked the references are fixed up properly. However, we would like to be able to use our own wizard to start the action because it brings up UI that makes most sense for our type of files. It offers options that are specific to our models. JDT variant is not doing that nor would it happen with the basic resource rename/move. As for parity between Package Explorer and Project Explorer I don't think it is fair to say that they have to be 1:1. Package Explorer is Java centric view. Project Explorer is not. In our particular case we had a UML centric navigational view which is replaced by Project Explorer. We would like to get that 1:1 parity as well but that is not going to be 100% possible - we are part of common navigational view now and some assumptions are just not valid anymore. As far as I can see at the very least the JDT actions should be used only in Java projects. That would probably be sufficient for 3.2. Going further, I think the basic resource rename/move should be used only if a specialized variant is not available. Ideally, I believe JDT actions should be only on resources it really knows about, regardless on the project nature. Created attachment 45955 [details]
\JDTRefactorIssue
JDT Refactor Issue
I had issues with Bugzilla - I found out that you cannot add "Additional Comments" and attachment and commit both in the same time - it added just the attachment and I lost my comments - I am including my comments below: This happens with Eclipse 3.2 RC5 as well - this is really bad for the user, that might fire a JDT refactoring in Project Explorer instead on other (custom/eclipse) refactor operation, without even knowing and without working with Java files(if project and files are not java nature). I am using Eclipse 3.2 and I really have to be carefull what refactoring action I am invoking (for other file type than java) - there is no visual clue that JDT refactor is invoked (e.g. Move/Rename Java File instead on Move/Rename action) and I was not able to turn this JDT refator action off from Project Explorer, so I will not get confused, since I do not work with Java Files. For example, the JDT Refactor -> Move action will let you move a file (any file type even .cpp) under any project type (under root location of the project - the OK button is enabled) and you can corrupt your files/references since IS NOT A JDT REFACTOR. However is not allowed to Create a Java Package from Move JDT Dialog if we do not have a Java nature project in workspace. When Select 'Create Package' button in JDT Move Dialog, the Finish button is disabe if there is no a Java nature project (I attached JDTRefactorIssue.jpg for workflow). From an user experience/perspective, please remove the JDT Refactor and JDT Copy/Cut/Delete/Paste for non-java related files o at least rename the Action Label to reflect what Refactor Operation is going to trigger... E.g. for JDT Copy/Cut/Delete/Paste and (most importantly) Refactor -> Rename/Move (on other files type than Java Nature )in Project Explorer (or any Eclipse Navigator View) change to Copy/Cut/Delete/Paste Java (file/element) respective Refactor -> Rename/Move Java (file/element) And the Rename/Move Dialog Title as well can be changed from Rename/Move to Rename Java (file/element) respective Move Java (file/element) The severity is more that major since can result in corruption of files. Thanks in advance, Magda Bologa I agree that there is potential for confusion here, but I do not think there is a safe, reasonable fix for 3.2.1, so I am deferring this to 3.3. Just wanted to let people interested in this bug know that bug 150838 is related to this issue and is partially targeted for 3.2.1. More details are available there. Boris, have you seen this one? Michael, I filed bug 157314 for the necessary changes in the CN. Could you try to address this in 3.3 M3 or M4? Any update for 3.3 ? The Refactor/Edit action split was apparently not ported to 3.3. It is addressed with the patch on bug 179719. The other portion of this problem is a duplicate of bug 157314. *** This bug has been marked as a duplicate of bug 157314 *** I don't think this should be marked as duplicate. The other defect is about overriding actions and that is resolved. However, if no override is available JDT actions will show up. That is still wrong. The other actions could be simply disabled because of active capabilities. Or they might not be present. But that still won't make JDT refactor move applicable for C++ classes. Or UML Model, for that matter, as in my case. Sorry, I was wrong. Yes, the other bug was updated will all the info and now it really is a duplicate. *** This bug has been marked as a duplicate of bug 157314 *** |