Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 350258

Summary: [WorkingSets] Share WorkingSets between Workspaces
Product: [Eclipse Project] Platform Reporter: Adam Wehner <adam.lucarz>
Component: IDEAssignee: Platform UI Triaged <platform-ui-triaged>
Status: NEW --- QA Contact:
Severity: enhancement    
Priority: P3 CC: prakash
Version: 3.6.2   
Target Milestone: ---   
Hardware: PC   
OS: Windows Vista   
Whiteboard:
Attachments:
Description Flags
Patch for sharing working sets definition by user. none

Description Adam Wehner CLA 2011-06-24 09:47:59 EDT 
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
Comment 1 Adam Wehner CLA 2011-06-24 09:48:56 EDT 
Created attachment 198533 [details]
Patch for sharing working sets definition by user.
Comment 2 Prakash Rangaraj CLA 2011-06-25 19:34:23 EDT 
Will investigate
Comment 3 Adam Wehner CLA 2011-06-30 09:04:31 EDT 
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?
Comment 4 Adam Wehner CLA 2011-07-30 10:44:30 EDT 
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.
Comment 5 Paul Webster CLA 2012-11-07 10:47:51 EST 
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