Community
Participate
Working Groups
Build Identifier: 20110218-0911 Hi, i work with different workspaces concerning different branches of projects. So the project names do not differ, but i had every time the problem that i have to manage the workingsets somehow. The import/export function helped a little bit, but i wondered why not share the working sets definitions between workspaces. So i have patched my eclipse (3.6.2) to save the workingsets.xml in the user directory (<user.dir>/.eclipse/org.eclipse.ui/workingsets.xml). So I do not have to bother about definition sharing. Which working sets are needed in a workspace can be handled by activation/deactivation them in the target workspace. A patch with my modifications is attached. I think this is helpful. What do you think? p.s. You can activate the sharing by the system property -Declipse.workingsets=@user.dir Adam Lucarz Reproducible: Always
Created attachment 198533 [details] Patch for sharing working sets definition by user.
Will investigate
Okay, that does not work properly, because not existing projects are deleted from a working set definition. So when you switch between workspaces, these projects disappear from the working sets. I will have another look on that. Meanwhile..any ideas how to disable this behavior?
Okay. I don't have a clue how to avoid the project disappear effect when working with different workspaces without changing the whole working sets definition read and write mechanism. So, I would request this feature here without providing a solution. Sorry for that.
Instead of using a system property, there's an OSGi location service that will provide the equivalent of the plugin state location. For example, a plugin state location is found using the following an appending the plugin id to the end of the path: public Location getInstanceLocation() { if (locationTracker == null) { Filter filter = null; try { filter = context.createFilter(Location.INSTANCE_FILTER); } catch (InvalidSyntaxException e) { // ignore this. It should never happen as we have tested the // above format. } locationTracker = new ServiceTracker(context, filter, null); locationTracker.open(); } return (Location) locationTracker.getService(); } You could use org.eclipse.osgi.service.datalocation.Location.CONFIGURATION_FILTER instead of INSTANCE_FILTER. The configuration location is per-user in the case where the eclipse install is read-only. The append the plugin id to the path, similar to the following: File baseLocation; try { baseLocation = new File(URIUtil.toURI(instanceLocation.getURL())); } catch (URISyntaxException e) { throw new RuntimeException(e); } baseLocation = new File(baseLocation, ".metadata"); //$NON-NLS-1$ baseLocation = new File(baseLocation, ".plugins"); //$NON-NLS-1$ baseLocation = new File(baseLocation, "org.eclipse.e4.workbench"); //$NON-NLS-1$ PW
