Community
Participate
Working Groups
With eclipse-SDK-I20070313-1051 on Windows XP SP1, Sun 1.5.0_11: * Launch Eclpse-3.3M5 and have it create a new workspace: E:\PDE>.\eclipse3.3m5.eh\eclipse\eclipse.exe -data .\testws * Go to Team > CVS > SSH2 Connection and change the SSH Homedirectory * Import a Team Project Set, quit * Launch Eclipse-I20070313-1051 on the M5 workspace: E:\PDE>.\I20070313-1051\eclipse\eclipse.exe -data .\testws * Window > Preferences * Expand General > Network Connections and click on it * Click on the "SSH2" node just below it --> Although nothing was changed, the following error dialog is displayed: Could Not Accept Changes The currently displayed page contains invalid values. Accept the dialog with OK. Click on SSH2 node --> nothing happens. Click back on Network Connections node, then SSH2 node --> now it works. But SSH2 home is empty. Note: when starting Eclipse on a new, empty workspace the default preference values are filled in correctly. The problem only appears when migrating an existing workspace.
Noticed that after setting the right SSH2 Home directory, the value also is not persistently stored: after quitting Eclipse and re-starting, the dialog "Could not save... invalid values" is still displayed and the SSH homedir is empty. Marking the bug as major, since most Eclipse users will migrate existing workspaces and this bug breaks their workspaces in an unrecoverable way.
When going to the SSH2 Prefs page in this scenario and pressing OK with the values still empty, a dialog pops up saying: Question does not exist. Are you sure you want to create it? Answering yes shows an error marker in the Prefs page: "Failed to create". Switching to the Known Hosts tab shows a completely empty tab without any control on it - even after a correct ssh homedir is filled in on the first tab. Perhaps that's the reason for the problem?
Created attachment 60904 [details] a patch to fix this problem. I found a bug and it is my fault. I hope that attached patch will fix this problem.
Patch released. Thanks.
Thanks for the patch... what I'm wondering is, will this also work when importing old-style Preferences through File > Import? For my many workspaces, I have come up with a set of *.epf files that hold my Preferences, and when I start a new workspace the first thing I do is importing one. By reading the code, it looks like such an import of an old-style SSH2 home would not set the new-style SSH2 home, but I did not try it out and I might be wrong.
(In reply to comment #5) > Thanks for the patch... what I'm wondering is, will this also work when > importing old-style Preferences through File > Import? > For my many workspaces, I have come up with a set of *.epf files that hold my > Preferences, and when I start a new workspace the first thing I do is importing > one. By reading the code, it looks like such an import of an old-style SSH2 > home would not set the new-style SSH2 home, but I did not try it out and I > might be wrong. If you import a set of your *.epf files before visitting at new SSH2 Preference page, I guess it will work well. In other words, the conversion will occur only one time. Should we check older settings forever if they are changed or not? It may be possible to write such a code, but is it reasonable from the policy point of view?
What if I import old-style prefs from a *.epf file but never visit the Prefs page? I don't think conversion should be tied to visiting the UI page. I'm not suggesting that the import functionality must be there, I'm just wondering if there is some common guidelines for this kind of things or perhaps even some generic functionality. Like calling the org.eclipse.core.runtime.preferences extension's "initializer" class after importing an *.epf file for instance -- to make sure that not only defaults are set, but also conversions can be done.
Actually, it seems to me that we should probably register an "org.eclipse.core.runtime.preferences" extension with a "modifier" slot to listen for modifications of the old-style preferences (which would happen on Import, I guess but have not tested) and make sure we apply those modifications on the new-style Preferences. Reopening the bug for this, but waiting for confirmation that this strategy is valid and in line with common habits.
(In reply to comment #7) > What if I import old-style prefs from a *.epf file but never visit the Prefs > page? Oops, my last reply was not enough and correct. The conversion will occur at the first access to the preference object of JSchCorePlugin. So, the conversion will also occur at the first CVS extssh access. It, however, may be not enough for your requirements.
*** Bug 177663 has been marked as a duplicate of this bug. ***
While I certainly agree that a deluxe solution would handle preference import, I think it is enough to support workspace migration (unless someone feels strongly enough about this to provide a patch ;-). We will document this in the porting guide for 3.3 (i.e. explain that, to share preferences, the user must migrate a workspace and then export the preferences to be shared for 3.3 workspaces).
Actually, this may be easier than I thought. There is a PreferenceModifyListener that gets called on preference import so the migration during import should be straight forward.
I released a fix that will also migrate during preference import. This required a bit of refactoring in the original migration code. I've tested it myself but any additional testing is appreciated.
