Community
Participate
Working Groups
1. To reproduce this, download the filedrag plugin from http://sourceforge.net/projects/sunshade. (The plugin is so simple it qualifies as a short test case.) 2. In an existing install of 2.1 in which the default workspace has been created and is not empty, exit Eclipse and unzip the plugin into the plugins folder. Restart Eclipse in the default workspace. 3. Verify that no Open... item appears immediately beneath the New... item in the File menu. 4. Close Eclipse again. Go to the default workspace .metadata folder and delete the workbench.xml file in the .plugins\org.eclipse.ui.workbench folder. Restart Eclipse in the default workspace. 5. Verify that an Open... item appears immediately beneath the New... item in the File menu. [Seen in Eclipse 2.1 final, WinXP] If this bug is as general as it appears to be, can someone suggest a workaround that plugin writers can employ to ensure their global scope actions are properly installed?
If this action is being contributed via an action set (which I hope it is, since that's the only way to do this through API), then you will need to manually enable it for any existing perspectives. This is a known problem.
The problem here appears to be with action sets getting slammed after the extensions in the plugin.xml is read. Reassigning and attaching the file drag example. BTW if you use the same example in a fresh Eclipse the new entry shows up no problem.
Created attachment 4648 [details] File drag example
This is the known problem where the workbench does not update when new plugins are installed after being run at least once. If you close the perspective and reopen again, you will see the action. Or you can reset the perspective.
Well, fix it. ;-} Install instructions: 1. Install plugin. 2. Close all open perspectives and re-open them. Pfui.
*** This bug has been marked as a duplicate of 6929 ***
