Question

I use multiple workspaces with Eclipse. I recently noticed that some of my workspaces have a lot of cruft in them from software packages that I installed and then later removed. As far as I can tell, the situation is that many packages write stuff (sometimes a lot of stuff) to the .metadata folder for every workspace I open while the package was installed. When I removed a package, it seems to clean out the .metadata folder for the workspace that I happen to have open at the time, but all the other workspaces are left with orphaned metadata. Sometimes this metadata causes problems—often, errors while opening the workspace and sometimes instability.

The only way I know to deal with this is to create a new workspace, import projects from the polluted workspace, reconstructing all my settings (a major pain) and then delete the old workspace. Is there an easier way to deal with this?

Answer 1

There is no easy way to remove the “outdated” stuff from an existing workspace. Using the “clean” parameter will not really help, as many of the files you refer to are “free form data”, only known to the plugins that are no longer available.

Your best bet is to optimize the re-import, where I would like to point out the following:

• When creating a new workspace, you can already choose to have some settings being copied from the current to the new workspace.
• You can export the preferences of the current workspace (using the Export menu) and re-import them in the new workspace.
• There are lots of recommendations on the Internet to just copy the ${old_workspace}/.metadata/.plugins/org.eclipse.core.runtime/.settings folder from the old to the new workspace. This is surely the fastest way, but it may lead to weird behaviour, because some of your plugins may depend on these settings and on some of the mentioned “free form data” stored elsewhere. (There are even people symlinking these folders over multiple workspaces, but this really requires to use the same plugins on all workspaces.)
• You may want to consider using more project specific settings than workspace preferences in the future. So for instance all the Java compiler settings can either be set on the workspace level or on the project level. If set on the project level, you can put them under version control and are independent of the workspace.