Community
Participate
Working Groups
Rename refactorings currently only consider Java files. As a result renaming a Java class that is referenced in a plugin.xml file too, doesn't update the plugin.xml file. There are two alternatives to solve this problem: 1.) do a textual find/replace on certain files too (for example files with the extension .xml). But this can lead to a wrong refactoring too, since it doesn't know anything about the structure of the xml file and might change occurences which aren't releated to the changed Java element. 2.) open the refactoring framework for other plugins so that PDE could supply its own plugin.xml refactoring. Short term should be (1), long term solution should be (2).
Dirk mentioned two possibilities when he opened this bug based on my report; I vote for the second one: "open the refactoring framework for other plugins so that PDE could supply its own plugin.xml refactoring", assuming that means "make the refactor-gizmo work on xml files the way it does on java files: i.e., in Java it knows where/how to look for imports, method-calls, etc. -- SO, in XML, it should know to look for tags or whatever they are called"
Seems to be a dupe of 299?
Here are two kinds of failures that show that refactoring should and could consider the plugin.xml file: In a project Foo, created by using the Plugin wizards (my tests were in a plugin that added an action to the main menu): a) rename the (wizard-generated) package in which the plugin's classes are found; there is one reference to that package for the FooPlugin.java class and one for the EditActionDelegate; see b and c for the effects of failing to change those references (if both are unchanged, go to # b). b) rename the EditorActionDelegate class; if the plugin.xml isn't made consistent, the action (if the plugin is an action) will appear in the runtime workspace, but will crash on invocation, with the stack trace below, and the message (in the console): "Plug-in <id of plugin> was unable to load class <package>.<wrong name of class>." java.lang.ClassNotFoundException: <package>.<wrong name of class> at org.eclipse.core.internal.boot.DelegatingURLClassLoader.loadClass(DelegatingURLC lassLoader.java(Compiled Code)) at java.lang.ClassLoader.loadClass(ClassLoader.java(Compiled Code)) at org.eclipse.core.internal.plugins.PluginDescriptor.createExecutableExtension(Plu ginDescriptor.java:148) at org.eclipse.core.internal.plugins.PluginDescriptor.createExecutableExtension(Plu ginDescriptor.java:185) at org.eclipse.core.internal.plugins.ConfigurationElement.createExecutableExtension (ConfigurationElement.java:97) at org.eclipse.ui.internal.WorkbenchPlugin$1.run(WorkbenchPlugin.java:103) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:98) at org.eclipse.ui.internal.WorkbenchPlugin.createExtension(WorkbenchPlugin.java:100 ) at org.eclipse.ui.internal.PluginAction.createDelegate(PluginAction.java:70) at org.eclipse.ui.internal.EditorPluginAction.createDelegate(EditorPluginAction.jav a:37) at org.eclipse.ui.internal.PluginAction.run(PluginAction.java:114) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionCont ributionItem.java:407) at org.eclipse.jface.action.ActionContributionItem.handleWidgetEvent(ActionContribu tionItem.java:361) at org.eclipse.jface.action.ActionContributionItem.access$0(ActionContributionItem. java:352) at org.eclipse.jface.action.ActionContributionItem$ActionListener.handleEvent(Actio nContributionItem.java:47) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java(Compiled Code)) at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:634) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:1282) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1092) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:673) at org.eclipse.ui.internal.Workbench.run(Workbench.java:656) at org.eclipse.core.internal.boot.InternalBootLoader.run(InternalBootLoader.java:81 5) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:285) at java.lang.reflect.Method.invoke(Native Method) at org.eclipse.core.launcher.Main.basicRun(Main.java:151) at org.eclipse.core.launcher.Main.run(Main.java:433) at org.eclipse.core.launcher.UIMain.main(UIMain.java:52) =========================================================================== c) given that the problem described in # b is not present, then rename the (wizard-generated) plugin class; if the plugin.xml isn't made consistent, the action (if the plugin is an action) will appear in the runtime workspace, but will crash on invocation, with the stack trace below, and the message (in the console): "Plugin <id of plugin> activation failed while loading class <package>.<editor action delegate class>" java.lang.ClassNotFoundException: <package>.<plugin class> at org.eclipse.core.internal.boot.DelegatingURLClassLoader.loadClass(DelegatingURLC lassLoader.java(Compiled Code)) at java.lang.ClassLoader.loadClass(ClassLoader.java(Compiled Code)) at org.eclipse.core.internal.plugins.PluginDescriptor.internalDoPluginActivation(Pl uginDescriptor.java:615) at org.eclipse.core.internal.plugins.PluginDescriptor.doPluginActivation(PluginDesc riptor.java:204) at org.eclipse.core.internal.plugins.PluginClassLoader.activatePlugin(PluginClassLo ader.java:52) at org.eclipse.core.internal.plugins.PluginClassLoader.findClassParentsSelf(PluginC lassLoader.java(Compiled Code)) at org.eclipse.core.internal.boot.DelegatingURLClassLoader.loadClass(DelegatingURLC lassLoader.java(Compiled Code)) at org.eclipse.core.internal.boot.DelegatingURLClassLoader.loadClass(DelegatingURLC lassLoader.java(Compiled Code)) at java.lang.ClassLoader.loadClass(ClassLoader.java(Compiled Code)) at org.eclipse.core.internal.plugins.PluginDescriptor.createExecutableExtension(Plu ginDescriptor.java:148) at org.eclipse.core.internal.plugins.PluginDescriptor.createExecutableExtension(Plu ginDescriptor.java:185) at org.eclipse.core.internal.plugins.ConfigurationElement.createExecutableExtension (ConfigurationElement.java:97) at org.eclipse.ui.internal.WorkbenchPlugin$1.run(WorkbenchPlugin.java:103) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:98) at org.eclipse.ui.internal.WorkbenchPlugin.createExtension(WorkbenchPlugin.java:100 ) at org.eclipse.ui.internal.PluginAction.createDelegate(PluginAction.java:70) at org.eclipse.ui.internal.EditorPluginAction.createDelegate(EditorPluginAction.jav a:37) at org.eclipse.ui.internal.PluginAction.run(PluginAction.java:114) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionCont ributionItem.java:407) at org.eclipse.jface.action.ActionContributionItem.handleWidgetEvent(ActionContribu tionItem.java:361) at org.eclipse.jface.action.ActionContributionItem.access$0(ActionContributionItem. java:352) at org.eclipse.jface.action.ActionContributionItem$ActionListener.handleEvent(Actio nContributionItem.java:47) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java(Compiled Code)) at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:634) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:1282) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1092) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:673) at org.eclipse.ui.internal.Workbench.run(Workbench.java:656) at org.eclipse.core.internal.boot.InternalBootLoader.run(InternalBootLoader.java:81 5) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:285) at java.lang.reflect.Method.invoke(Native Method) at org.eclipse.core.launcher.Main.basicRun(Main.java:151) at org.eclipse.core.launcher.Main.run(Main.java:433) at org.eclipse.core.launcher.UIMain.main(UIMain.java:52) ============================================================================
*** Bug 299 has been marked as a duplicate of this bug. ***
We would like to have this feature, but is is not a priority for 2.0. Postpone > 2.0
How is "Later" a resolution? What Mozilla does with bugs they don't want to solve immediately is that they assign the bug to "nobody@mozilla.org" and add the keyword "helpwanted". IMO, it would be great if you guys could do the same. Some advantages of that is that: * Unresolved bugs aren't marked as "resolved"... * Easy to for people who want to help to find out where help is needed.
Good suggestion. We already started to flag PRs with 'helpwanted' but we don't assign these bugs to nobody@oti.com. We are looking into changing our procedure accordingly.
I agree with Dirk, currently nobody is me...
If this might increase its priority ("increase" in the sense of "sooner") here's another case: create, compile, etc. a plugin Foo; all is well create, compile, make dependent upon Foo another plugin Bar; all is well now rename the *project* Foo to Food. Ooops -- Bar barfs, and one needs to go both to Bar's manifest editor to reset the dependency from Foo (still oddly a possibility) to Food by hand, and also go to Bar's Project properties and reset the project reference from Foo (still oddly a possibility) to Food by hand.
I got burned by this as well and I would really like to have this feature. As has been suggested in this bug there is 1) a quick and dirty way (text search) or 2) supporting refactoring in other file types. We should do 2) but 2) is work and we can't commit to it for 2.0.
Not clear yet if refactoring will become public in 2.x or 3.x
*** Bug 27035 has been marked as a duplicate of this bug. ***
We should also consider working sets and lauch configs when introducing refactoring participants.
option to search in non-Java file is now available.
