Community
Participate
Working Groups
M4 build Jeff says: I don't remember if it was you who mentioned that we used to have some dialog that would come up when you first started an old workspace using a new eclipse. Coming up to 2.1 it would be good to make this work for 2.0.x workspaces. The main problem scenario is when a user mistakenly or unwittingly starts a new eclipse on an old workspace and some/all of their metadata gets migrated forward for them. This has the potential for making their workspace useless under the old eclipse. I wonder if this is really "notice that the workspace was from a different minor verision (e..g, 2.1 vs 2.0) and put up a generic dialog allowing the user to exit without consequences.
How do we determine which version of eclipse was used to generate the workspace being restored? I can not use the version of any particular plugin for this information as any one particular plugin may eventually freeze, while eclipse continues to evolve. For example SWT may eventually say "we are done" yet new features are introduced by core/ui for 10 release on. I would not expect the SWT plugins to increment their version in such a circumstance. If I saved my workspace with R2.0, and I now want to run with R2.1, there needs to be a mechanism in place that stored the fact R2.0 was used to save the workspace. When R2.1 runs the first thing it does is check what version was used to store the workspace, and then allow the user to abort there and then. If it is not detected immediately partial migration of some .metadata may already have happenned. What process is used to determine when an incompatible change has occurred? If I create a workspace using R2.0, then migrate to R2.0.2 I may be told I can't go back to R2.0. But if I was too boot R2.0.1 (which for arguement sake is compatable with R2.0.2) I would not expect a warning. How about supporting going backwards? If as a user I decide to use R2.1, upgrading my R2.0 workspace in the process I may need to go back to R2.0 if there are major issues with R2.1. Perhaps the ability to migrate back/forward one release should be supported.
It's not necessarily just the workspace version either. There may be other transformations going on in plugins other than org.eclipse.core.resources. Jeff, do you know the list of cases we need to handle, and how we can get the (old and new) version info?
Need help on this one.
Please investigate whether it is possible to defer activation of org.eclipse.core.resources until after a dialog can be brought up. This will require some restructuring to avoid any references to classes in org.eclipse.core.resources from class Workbench, due to the verifier bringing them in and activating the plugin. Suggest moving all refs to another class, e.g. CoreAccess.
Nick, what was decided on this?
See also related Core bug 34031.
No changes to Platform UI for this in 2.1. See comments in bug 34031. For 2.1.1 or 2.2, we will consider changing eclipse.exe to do this check.
Need to add the workspace metadata version check for 2.1.1. There are two problems with doing this in eclipse.exe: 1. eclipse.exe does not know the workspace location. 2. We want to avoid UI code in eclipse.exe, since it must then be ported to every platform. eclipse.exe already does have UI for bringing up a message dialog though. Kevin, how hard would it be to extend this to allow an OK/Cancel or Yes/No dialog? If we had this, then the flow could go as follows: - eclipse.exe launches org.eclipse.core.launcher.Main - the runtime determines the workspace location and checks the metadata version - if it's consistent, then it proceeds as normal - otherwise, it exits with a special error code indicating the metadata version is inconsistent - eclipse.exe recognizes this and brings up a dialog with an OK to proceed or Cancel to quit - if OK, then it relaunches Main with a new command line arg saying to skip the version check
Nick, the logic you describes should work. I did a quick check to determine how easy/difficult it would be to display an OK/Cancel dialog for the various platforms: Motif - use XmMessageDialog() with different flags Win32 - use MessageBox() with different flags GTK - use gtk_message_dialog_new() with different flags Photon - use PtAlert() instead of PtNotice() MacOSx (Carbon) - it only uses fprintf(consoleLog) so there might be a problem here (don't know if the console log supports standard in or if there is a message dialog that can be displayed instead ... I have never worked on a Mac Assuming the next "special" exit code is 16, the launcher could restart the JVM with an extra parameter (e.g., -noVersionCheck). There is one potential problem. The launcher has no I18n support. Currently, all of its messages are simply in English. At the C code level, it is quite difficult to determine the language/locale in order to display the appropriate message, especially since every platform does it in their own way. This I18n support could be a lot of work. Up to now, the messages output by the launcher were error related and could be left in English because they should not happen. This new message will be noticed by a majority of users who upgrade. The decision is not mine to make ...
Does anyone else think the fact that we have to exit from Java in order to be able to print a message is stupid? I believe Kevin's comment about localization is a telling one: We can't honestly expect to put up an english message in this case, since it is only a warning, and is something which we expect all workspace-upgrading users to see. I believe we should not do this in the C code. I think I would be happiest if we just pulled SWT out of the plugin it is currently in and made it part of the "system classes" for Eclipse (i.e. "put the jar on the command line"), then allowed core.boot to invoke SWT classes as required. Note: I understand that there is a headless usecase. We would need to handle this gracefully, by having an API layer which checked a flag (or the existance of the SWT classes) and did not attempt to prompt. In any case, I do not believe this is something which should be done for 2.1.1. However, I am in favor of doing it for R3.0.
Ah yes, NL. Another reason why we want to avoid UI code in C (not to mention the extra bogus restart). The other option is to do this via a special eclipse application that gets run before the Workbench if the versions are inconsistent. This would depend on SWT and would avoid activating any other plugins. I suspect that this would have to be run after the update reconciler though. If so, we need to ensure that, if the update reconciler runs on a 2.0 workspace being opened with a 2.1-based product, the user can go back and open it using a 2.0-based product with no ill effect. Dejan, do you see any potential problems here? Would it be possible to run a plugin that depends on SWT without running the update reconciler first? It should not care about any feature details. If the update reconciler does run, do you see any problems if the user cancels and goes back to 2.0?
Code is ready to be released. The code is in two parts: 1. version check in InternalPlatform (org.eclipse.core.runtime), which is called from InternalBootLoader.run (org.eclipse.core.boot) just before launching the main application (or the update reconciler) 2. new plugin org.eclipse.ui.versioncheck to prompt the user if the workspace metadata version differs from the expected version See attached screenshot for what the dialog looks like. Also added new command line arg, -noversioncheck, to skip the check completely, e.g. for headless scenarios. Part 1 needs to be reviewed by Core. Part 2 is waiting on approval for the new project.
Created attachment 4983 [details] Screen shot of version check dialog
Reviewed and released Core code into R2.1.1 maintenance branch.
Released new org.eclipse.ui.versioncheck plugin to both the 2.1.1 and 3.0 streams. Asked releng to update the corresponding features.
Fix made it into build M20030528. There was a problem whereby the test harness was doing a hard exit, which caused Eclipse to skip writing the version file and thereby issue a version check prompt on the next run, hanging the tests. The test harness was fixed for M20030530.
Marking as Fixed.
Verified in build M20030602.
