Community
Participate
Working Groups
Created attachment 111361 [details] eclipsePluginProblem.PNG Build ID: M20060921-0945 Steps To Reproduce: 1. I am trying to create an identical clone of a workspace on a different machine 2. I get the attached message 3. The windows are open as I left them on the original machine, but the plugin's are not available More information: eclipse 3.2 on debian stable
If the plug-ins are not installed then Eclipse naturally cannot restore the views that were originally contributed by the plug-in. This is what the error dialog is trying to convey. I'm not sure I understand what the problem is here.
hmm, the plugin is present. I did "tar -cvzf workspace.tgz ~/workspace" and unpacked it on the new machine again. The only difference is that the user on the destination machine is not the same. So, it may look in the work place for some plugins even though I correctly adapted the workspace property So, the workspace/.metadata/ with its entire .plugin is present on the new machine as well. So, if it is looking for some file in a destination that doesn't exist, I'd hope it amends the error with what it is looking for and that it did not find that directory
(In reply to comment #2) > hmm, the plugin is present. > > So, the workspace/.metadata/ with its entire .plugin is present on the new > machine as well. Hint: Plug-ins are not stored in that folder. I guess you technically could (maybe?), but I know of nobody that stores plug-ins there.
ok, in the .metadate apparently are only a directory with the plugin's java class-name is present. Now found the *.jar's of the plugins are in the ~/.eclipse directory, but I still get the same error when starting up eclipse Any hint how to find out where it searches for it short of doing an "strace"
(In reply to comment #4) > ok, in the .metadate apparently are only a directory with the plugin's java > class-name is present. Actually, those aren't Java class names, but anyway... > Now found the *.jar's of the plugins are in the ~/.eclipse directory, but I > still get the same error when starting up eclipse > > Any hint how to find out where it searches for it short of doing an "strace" I'm not sure if strace is going to help here personally. In any case, I noticed you are using Eclipse 3.2 on Debian, did you get Eclipse from the Debian repositories? If yes, I suggest you get Eclipse from eclipse.org. For your information, Eclipse 3.2.0 itself is over two years old and the last maintenance release, 3.2.2, is over one and a half years old.
Menu "Help" - "Software Update" - "Manage Configuration" - "Add Extension Location" and entering ~/.eclipse did help - but why does it forget that and not blame, it doesn't know where to search or rather list the directories it DOES search? Thx for the hint for taking another eclipse version, just trying to avoid doing too much of config myself
(In reply to comment #6) > why does it forget that Hard to say. I'm not even totally sure if you're running two separate Eclipse installations or the same one. Also, did you install Eclipse from Debian's repository? If yes, Debian may have done some plug-in detection thing to get it working with ~/.eclipse/ or something. I can't say more because a) I don't use Debian and b) I use Eclipse builds from eclipse.org directly. > not blame, it doesn't know where to search or rather list the directories it > DOES search? Where are you suggesting this be listed? By default Eclipse 3.2 is just searching in eclipse/plugins/ as far as I know.
> Where are you suggesting this be listed? By default Eclipse 3.2 is just > searching in eclipse/plugins/ as far as I know. IMHO, this should be listed in the error message "Could not restore workbench layout" as attached. I.e.: if the config from the workspace has some views open and the plugins to create them are not found, I) say that in "~/eclipse/plugins/" or wherever the defalut location is, no corresponding plugin was found II) say where you found the hint that such a "orphaned view" does exist e.g. which xml tag in workspace/.metadata/.plugins/org.eclipse.ui.workbench/workbench.xml or alike
(In reply to comment #8) > IMHO, this should be listed in the error message "Could not restore workbench > layout" as attached. I.e.: > > if the config from the workspace has some views open and the plugins to create > them are not found, I am not sure if this solution would actually scale since not having the plug-ins is simply one of a variety of reasons why a view couldn't be created. It could just as easy be a typo issue or an issue with the code not being as robust as one would like that causes the view to fail to be created.
Ralf, thanks for the info. I'm already slated to take a crack at this in 3.5. As Remy points out there are a number of ways that we can 'fail' to be able to restore a part. Some (like missing plugins) are even 'expected' under certain conditions (like uninstalling a plugin). *** This bug has been marked as a duplicate of bug 218197 ***
