Community
Participate
Working Groups
M5 + patches 1. Launch eclipse 1.0. Create a project p with a class test.Main including a main method with the text "System.out". This should give you 1 error in the task list. 2. exit eclipse 3. launch eclipse 2.0 and point at the workspace created above. Eclipse 2.0 notices that you have an old workspace and gives you two choices: A. convert the project and proceed B. cancel and leave the workspace as is. If you select B, cancel and leave the workspace as is, you are left in a state where the workspace is not readable by Eclipse 2.0 nor Eclipse 1.0. Eclipse 1.0 thinks the project p has been deleted; Eclipse 2.0 thinks the project p is closed and doesn't want to open it.
If Cancel is chosen at the prompt, the Workbench does a clean exit (returns null from Workbench.run), and does not modify the workspace in any way. If OK is chosen, the workbench.xml file is deleted and a new window is opened. Again, no modifications to the workspace are made. The main difference between choosing OK and Cancel, as far as Core Resources is concerned, is that the workspace is not saved before exiting. Since the workspace proper should be 100% compatible between 1.0 and 2.0, this is apparently a deeper issue with Core Resources itself, as opposed to how the Workbench uses it. Whether we save the workspace in 2.0 or not, it should still be readable in 1.0. This is apparently hitting a lurking problem in Core. Tracing through it, Core Resources gets activated while instantiating the Workbench (see below for why). When Workbench.run exits, the platform shuts down all plugins. Since Core Resources was activated, ResourcesPlugin.shutdown() gets called. This calls Workspace.close, which in turn calls Project.close on all projects. There is code in Project.close which deletes the project (but not its contents) if the workspace has not been saved. In this case, the workspace has not been saved, so all projects get deleted. This logic is marked with: //FIXME: revisit this behaviour of deleting if not saved Looks like we should revisit it now <g>. Doing this may make sense for a new workspace, if it needs to wipe out any info written for new projects on exit without save. But it does not make sense to make any modifications to a previously existing workspace if no changes have been made. I also noticed that, since the project is being deleted, the move/delete hook is causing the org.eclipse.team.core plugin to be activated during shutdown. This is kind of scary. This will go away if we avoid deleting on shutdown. Now, why does Core Resources even get activated in this situation? Ideally the Workbench would not activate Core Resources before this dialog is brought up, but it does. (Even more ideally, the Workbench proper would have no dependencies or references to Core Resources, but we're a long way from that.) The Core Resources plugin is activated during instantiation of the UI application (org.eclipse.ui.internal.Workbench). This occurs while it's still in the newInstance call, before Workbench makes any explicit references to Core Resources. This is most likely due to WorkbenchPlugin having a method signature referring to a type in Core Resources: WorkbenchPlugin.getPluginWorkspace() (a convenience method) returns an IWorkspace. In any case, we do currently make some explicit references to Core Resources before bringing up the dialog (registering adapters). While it may be possible to avoid activating Core Resources before the Workbench is fully initialized, this is not a simple change. Moving to Core to address the problem with project deletion on shutdown.
Simply commenting out the delete in Project.close allows the workspace to be reopened in 1.0. I don't claim that this is the correct fix though. It seems strange to even bother doing the work of closing projects on shutdown. In addition to taking time, it's unclear that it's the right semantics. I think of a project's open/close state as remaining unchanged across shutdown and restart. If the issue is notifying listeners about shutdown and restart, this should be done explicitly, not via close/open.
This was an issue with how workspace handles closing. Historically, there was API for clients to close and open the workspace as often as desired, so workspace close had to make sure nothing was left behind in the workspace tree. The problem manifests itself in this case because the "has this project been saved?" check is implemented by looking for the .project file. Since the 1.0 workspace has no .project files, it appears that these projects have never been written to disk, so it removes them from the workspace tree. The fix was two-fold. First, cleanup the code in project close so that it DOES NOT delete the project meta-data if it hasn't been saved. The metadata area is always left in a consistent state by either save or snapshot, so there is no fear of a partialy written project meta-area. Second, avoid closing projects on close altogether. The only purpose of this was to notify our internal infrastructure so that they could do the appropriate cleanup (close property stores, clear caches, etc). Instead of closing, we now explicitly just call our infrastructure lifecycle method, workspace.closing(IProject).
