Community
Participate
Working Groups
When a software organize its work using workspace directories, it is a natural expectation, from the user's point of view, that the workspace directory can be renamed or moved to another location without any negative impact. Such an expected behaviour doesn't apply to the Eclipse workspace: if you rename, move or copy your workspace's directory, there are high chances that something goes wrong. In my experience, for example, if you have Maven hierarchical projects in your workspace, and you try to move / rename / copy the workspace, when you open the new one, the child projects appears closed, and if you try to reopen them, you get this error message: > "The project description file (.project) for 'foo' is missing. > This file contains important information about the project. > The project will not function properly until this file is restored.". Even worse, you cannot restore the workspace easily, because if you try to bring back your workspace to the original location, you find it corrupt and you have to manually reopen each Maven project and cross fingers. "Grepping" the workspace directory, I found that the ABSOLUTE path of the workspace directory is present inside several files: for example, I have found it inside the .location files in the .metadata directory. I wonder why such locations are not expressed always by the means of relative paths? Using absolute paths inside the workspace make it completely immovable! Copying the workspace is the worst case, because after the copy you have your new workspace pointing to folders of the existing old one! If the presence of absolute paths is required for some weird reason, it would be a nice enhancement to provide a new "rename / move / copy workspace" tool inside Eclipse.
Hey Giulio, I personally agree and had expected less problems from moving a (self containing) workspace. I have checked some of my workspaces and projects and found some with a location file (absolute path) and some without. It seem to be the case that only projects placed in the root of the workspace (default location / as sibling of the .metadata directory) are described relative. I have not directly seen a reason for the location URI to be absolute. But I would expect it to be easy or without risk to change. In the end a separate export page might be the more simple fix. However someone need to implement it and unfortunately no one had expressed interest for this topic yet. In the meantime the following workaround might satisfy your wish to copy a workspace (although it is not very different to your "copy, fix project and pray" attempt). When switching workspace from within Eclipse you have the option to copy layout, working sets and preferences into the new workspace. After that you can manually copy the projects to the new location and import them in the new workspace.
(In reply to Paul Pazderski from comment #1) > ... > In the meantime the following workaround might satisfy your wish to copy a > workspace (although it is not very different to your "copy, fix project and > pray" attempt). When switching workspace from within Eclipse you have the > option to copy layout, working sets and preferences into the new workspace. > After that you can manually copy the projects to the new location and import > them in the new workspace. Hi Paul, thank you for the reply. I tried your workaround and it seems to work like a charm. I followed your instructions, copying three Maven projects with several sub-modules, and they have been imported correctly: I used the "Import" > "Existing Projects into Workspace" function, with the "Search for nested projects" option checked, and I found all the projects in my new workspace, with all their sub-modules, and apparently without any compilation or configuration error. I also tried to avoid the manual copy of the projects folders into the new workspace, using the "Copy projects into workspace" option, but this way I lost the hierarchical structure of the Maven projects, so your way is better. A tip: when I was trying your workaround, I discovered that the "option to copy layout, working sets and preferences" is showed only if you switch workspace to a new one which is not present in the list of workspaces already known by Eclipse: you can remove any item from it going to "Switch Workspace" > "Other..." > "Recent Workspaces" > right click > "remove from launcher selection", or editing the $ECLIPSE_HOME/eclipse/configuration/.settings/org.eclipse.ui.ide.prefs file (thanks to https://stackoverflow.com/a/26550841),.
See also Bug 515074 in which we suggest to add the copy option also to the initial workspace selection dialog
