Community
Participate
Working Groups
Currently the Orion UI provides the user with one workspace and does not allow the user to have a second workspace. The user in fact only sees projects and does not know anything about a workspace. We still expose the server capability to create a second workspace. In theory the second workspace does not work and is supposed to be ignored. I am increasingly confident that rogue second workspaces are being created in production servers and are causing issues. Orion uses one workspace named "Orion Content" but we have an open hole that allows the UI to create a workspace with "some other name". We also seem to have issues about creating projects with the same name in multiple workspaces and I suspect this issue is what is causing the random JUNit tests failure with "Duplicate project name" ( see Bug 439728 ). I am going to close the hole of allowing the user to create a second workspace. I will update all the server JUnits to share the common "Orion Content" workspace like we use in the UI. We can look at introducing multiple workspaces again when the UI supports them correctly and we have sufficient tests for them.
I am making this major to highlight the issue. I have a server where I have an anthonyh-OrionContent and an anthonyh-OrionContent1 workspace. I do not know how or when anthonyh-OrionContent1 was created, it does not own any projects, and nothing seems broken but the second workspace existence just cannot be a good thing.
I am ok with disallowing this at server API level right now since it is not exposed in the UI. I would like to retain as much of the architecture as possible on the server to support this, because I think in the future it will become important once real world users are regularly using cloud IDEs. E.g., I think most people could not imagine Eclipse not supporting multiple workspaces and eventually I think the same will be true for Orion.
(In reply to John Arthorne from comment #2) > I am ok with disallowing this at server API level right now since it is not > exposed in the UI. I would like to retain as much of the architecture as > possible on the server to support this, because I think in the future it > will become important once real world users are regularly using cloud IDEs. > E.g., I think most people could not imagine Eclipse not supporting multiple > workspaces and eventually I think the same will be true for Orion. I plan to leave the server API and infrastructure as is. When you ask to create a workspace the expectation is that this will succeed. For now I am going to introduce a hook at gives you the workspace you already have when you ask for a new (second) workspace.
Fixed with commit: http://git.eclipse.org/c/orion/org.eclipse.orion.server.git/commit/?id=9cfd8b610081cf26de5ef670cd46ecb7915ba5eb With the simple2 version of the metadata storage format, when you try to create a workspace, you may see the informational message: SimpleMetaStore.createWorkspace: workspace name conflict: name will be "Orion Content": user anthony provided Orion Sandbox instead. When you try to create a second workspace, you see the informational message: SimpleMetaStore.createWorkspace: workspace conflict: cannot create a second workspace for user id: anthony, existing workspace is being used: anthony-OrionContent This should help identify the code path that is making a second workspace rather than using the one that is already there.
