Community
Participate
Working Groups
Remove configuration state from workspace metadata area. Feature and plug-in configuration state is currently stored in the metadata subdirectory of each workspace. This has the drawback that product configuration actions done in one workspace do not carry over to other workspaces. Configuration state should be moved out of the workspace into the install directory (single-user installs) or to a dedicated read-write product configuration area (shared multi-user installs). This would mean that configuration states would be in a known location for external tools to find. Different workspaces might still have different configurations, which could be achieved by referencing a named configuration state stored centrally. [Platform Update] [Theme: Rich client platform]
See bug#36101 for a patch to add a site on a per user basis...
I know this may seem a bit obvious but, If the configuration is going to be held centrally I think you should put it relative to the current users directory as on UNIX systems I put my eclipse install in a directory only root can write to, and I do my editing under a different id. If you used a central location that was in the eclipse directory, as is currently the default for the workspace, the workbench wouldn't work.
We have considered this scenario. Currently, we plan to coordinate our efforts with other Eclipse teams so that all the plug-in follow the same strategy re application-scope settings. Our current proposal is to use the following algorithm: 1) If state can be saved directly in the Eclipse install location, do it (the simplest scenario) 2) If save fails (a test for read-only state may be needed), or if shared install is explicitly requiested (using something like '-shared' command line argument), we would save the state in user.home, whatever that means on the platorm. Since multiple application may save there, we would create a unique application name space using a suitable ID (currently such an ID exists in .eclipseproduct marker file). Note that this is still an early proposal - don't count on the final solution being as described above. The bottom line is that your scenario is recognized as important to support.
Platform UI plan item tracked by the bug 36965 contains the notion of the 'application scope' that can be tapped into when saving the configuration state.
Released patch submitted by Dorian to repository for the M3 warm-up build on Monday AM.
As a follow-up to Dejan's comment #4, we have released the patch which places the .config in /<user-home>/.eclipse/<product-id>_<version>. Like Dejan mentions, the right solution is to take advantage of new API which comes out of the User Settings discussions. Since this new API is not yet available, we have decided to release this patch for now and will migrate to the new API when it becomes available. Note that there is potential for the directory location to change with the new API but we have decided that the benefit of more testing of this patch outweighs the risk of the directory location changing.
The update state has now moved to the configuration directory returned by the Platform.getConfigurationLocation() API. Closing the bug.
