Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #139319 +++ Many of our customers work with different branches / views of a single project at the same time, or have other reasons to work on multiple workspaces imultaneously. Currently, a separate Eclipse instance needs to be launched for each workspace, which has several drawbacks: (1) On Mac OS X, multiple instances of an app are problematic (bug 139319) (2) Resource Trees or behavior cannot be compared easily across different workspaces (partially going to be addressed by bug 139319) (3) Search cannot span multiple workspaces (4) User Preferences, which should be applied regardless of workspace, cannot be shared easily (bug 112130) (5) Multiple Eclipse Instances require more system resources than a single instance; startup time of Eclipse itself occurs multiple times, leading to user workflow disruption I would like to see the possibility of having multiple workspaces inside Eclipse like described in bug 139319 comment 22. The workspaces should remain totally separate conceptually. That is, operations in one workspace must run without disturbing similar operations in another workspace. Assuming one Workbench Window is open for each Workspace, the user experience should be the same as multiple Eclipse Instances, but with the added capability of shared Preferences, optionally spanning search, an spanning comparisons.
PS We are thinking about this in the context of E4, where the concept of a "Session" might simplify implementation of multiple simultaneous workspaces. I'm wondering how big of a rock this would be, assuming that multi-workspace should be transparent for existing clients and APIs?
The first thing to keep in mind is that there are multiple meanings to the word "workspace". When Eclipse first starts, the user is prompted to "select a workspace". This actually refers to the platform instance location (see Platform#getInstanceLocation() or org.eclipse.osgi.service.datalocation.Location#INSTANCE_FILTER). This location is used by all bundles to store metadata that needs persisting across sessions. It is sometimes also referenced in the API as the "platform working area". The resources plugin uses the platform instance location in three ways: 1) It stores its own metadata there (under workspace/.metadata/.plugins/org.eclipse.core.resources) 2) It uses that location as the *default* location for projects 3) It is the return value of IWorkspaceRoot#getLocation() The only place in the API where any of this is specified is in the class comment of IWorkspace, which states: * ... The default workspace data area * (i.e., where its resources are stored) overlap exactly with the platform's * data area. That is, by default, the workspace's projects are found directly * in the platform's data area. Individual project locations can be specified * explicitly. You will note that it says the "default" workspace data area. This leaves open the possibility of a workspace location that does not overlap the platform instance location. Thus the approach I suggest for this enhancement is to decouple the "workspace location" as defined by the resources plug-in from the "platform instance location" as defined by the Equinox framework. This would allow multiple workspaces, either open at the same time, or one at a time. I think this would also require IWorkspace to have a "closed" state like projects have today. There is some support for this in the implementation already with the Workspace#open and Workspace#close methods.
> ... This location > is used by all bundles to store metadata that needs persisting across sessions. > It is sometimes also referenced in the API as the "platform working area". > > The resources plugin uses the platform instance location in three ways: > > 1) It stores its own metadata there (under > workspace/.metadata/.plugins/org.eclipse.core.resources) A problem related to this is local history. If I have a single physical folder, loaded as a project in two eclipse workspaces, each workspace maintains a separate history for changes to identical files. Also, if one workspace is compiling with PDE target A, and another against target B, then the "/bin" folder in that project is invalid each time I switch workspaces and a full rebuild is required. One might argue that (for many use cases) there is no current support for multiple workspaces.
Thanks Randy. My understanding was that for the vast majority of use-cases, the multiple workspaces would typically not overlap but relate to different tasks / different branches which need to be separate anyways. Or can you explain why you'd want the same file/folder in multiple workspaces?
> Thanks Randy. My understanding was that for the vast majority of use-cases, the > multiple workspaces would typically not overlap but relate to different tasks / > different branches which need to be separate anyways. Or can you explain why > you'd want the same file/folder in multiple workspaces? (Maybe the platform team could provide more insight, since they implemented the support for this feature, but here goes...) One reason is that you work with "project sets" A, B, and C. A are dependencies shared by both B and C, which are unrelated to each other. Perhaps B and C are two different (large) eclipse-based products. Or, B and C are different streams of the same projects. Another reason I mentioned in comment 3, but I'll generalize here. There are several preferences that can only be set once for the entire workspace, such as the PDE target. So, to switch between settings for those preferences, you have to create another whole workspace and reference the projects from the original workspace. Or worse, you give up and say things like "Product xyz only support eclipse x.x". I'm not sure that multiple eclipse workspaces are really what's being requested here. Maybe what is needed is: - a more hierarchical management of projects, including the ability to open/close(/disable?) large sets of projects. - enhancements to tools like the PDE. For example, in Apple's XCode, I can easily switch between (real|simulated) iPhone (2.0|2.1|2.2) target.
(In reply to comment #5) > I'm not sure that multiple eclipse workspaces are really what's being requested > here. Maybe what is needed is: I personally would like to be able to work on Mac OS X with multiple workspaces of Eclipse at the same time and have a window per workspace open without resorting to workarounds. I'm used to this setup from Windows. I usually work on my main "project" (tens of Plug-in projects) in one workspace and use the other window/workspace (with lots of imported Eclipse source projects) as reference to look up how-to, due to miserable state of documentation of the most parts of the platform.
Could you have the kindness to provide an update on this request? Thanks a lot.
(In reply to comment #7) > Could you have the kindness to provide an update on this request? > Thanks a lot. Personally I suspect this will never happen. I actually implemented the core.resources part of this last year as an experiment, and it was not too difficult. See org.eclipse.core.resources branch v20100504_MultiWorkspace. It was about two weeks of work, and there would probably be another month of work to polish it off completely. This worked well as long as no other plugin depending on org.eclipse.core.resources is ever installed. The problem comes when you try to port any plugin to support multiple workspaces. There are literally thousands of calls to methods like ResourcesPlugin.getWorkspace() and IDEWorkbenchPlugin.getPluginWorkspace() within the Eclipse Platform SDK alone. Each one of those places needs to be replaced with code that knows *which* workspace is appropriate for that caller. This requires either maintaining extra contextual information about the workspace, or tying the workspace to some other singleton such as IWorkbench or Display, with obvious limitations. There are of course possible solutions to these problems, but from initial investigation I think it would be many person-years of effort to get even the base classic SDK fully supporting multiple workspaces. And then, any plugin you install would likely not understand this and fail to operate on the workspace you expect.
(In reply to comment #8) Most of the time when we need such feature, it is because we want to avoid switching back and forth between workspaces because of the loading time. If the workbench could know which is the "current" workspace, we could assume that each call ResourcesPlugin.getWorkspace() would return the current one. In this case, switching back and forth between workspaces would take only few milliseconds (or seconds if we need to rebuild it) and we could handle as many WS as we need. Does it make sense or do I miss something? Thanks
> (In reply to comment #7) Having distinct workspace sounds hard for the reasons you outline. However I wonder if the same namespacing effect could be achieved by some other means. For example instead of getWorkspace("Name"). What if you still had one WS, with multiple namespaces, so something like: WS.getProject("name", "namespace"). The problem then becomes slightly more tractable. You could build the workspace using fullpaths like /<namespace>/projects/folder/files (or /project/<namespace>/folder/files if you want to support bad users who get project name from segment 0 of the FullPath...). IResource#getProject and #getParent does the right thing by default Guaranteed there would still be some breakage. However with linked resources, API consumers need already to be careful about inferring fullpath -> location mapping, so mangling the path with a namespace may not be as problematic as it at first seems... The main utility I see for this is being able to checkout the same ProjectSet multiple times into the same eclipse session. Then search, compare, etc. is able to span multiple logical resource sets.
We setup a Java workspace and a Data workspace for each client we work with and have multipal instances of eclipse concurrently. The data workspace allows us to do work and make changes to data stores (databases and LDAP via Apache Studio plugins, in our case). We switch back and forth making change to one and testing form the other to see results. Works well on Windows and Linux, but now some of our team members are on MACs and we have to do work-arounds to open Eclipse in more than one workspace.
(In reply to comment #11) > Works well on Windows and Linux, but now some of our team members are on MACs > and we have to do work-arounds to open Eclipse in more than one workspace. I assume with "workarounds" you mean: making copies of the Eclipse application? Because that's all you need if you want to work with more than one workspace.
Well, no, if you mean installing again. That would be even worse. I wrote an automater workflow (Called EclipseAgain) that calls: /Applications/developement/eclipse.sh Which is: ECLIPSE_HOME=/Applications/developement/eclipse open -n $ECLIPSE_HOME/Eclipse.App This is how we always launch Eclipse on OS X. (10.6) Works, but many people would not know how to do such things.
(In reply to comment #8) > The problem comes when you try > to port any plugin to support multiple workspaces. There are literally > thousands of calls to methods like ResourcesPlugin.getWorkspace() and > IDEWorkbenchPlugin.getPluginWorkspace() within the Eclipse Platform SDK > alone. Each one of those places needs to be replaced with code that knows > *which* workspace is appropriate for that caller. This requires either > maintaining extra contextual information about the workspace, or tying the > workspace to some other singleton such as IWorkbench or Display, with > obvious limitations. John, I think you're setting too high a goal for this problem. Let's keep the existing assumption of a master workspace as maintained by ResourcesPlugin.getWorkspace(). But let's at least allow new code to open secondary workspace instances. I have a use case where we want to open an existing workspace to determine the list of external projects so as to link them into a new workspace. Currently I'm trying to avoid parsing the .metadata/.plugins/org.eclipse.core.resources/.root/XXXX/.location files by creating a Workspace instance and using reflection to configure a LocalMetaArea instance. Not very fun!
Here are some fresh news on this topic: https://dev.eclipse.org/mhonarc/lists/platform-dev/msg01244.html . Those are a must read for whoever is interested in this idea.
