Community
Participate
Working Groups
In order to ease user experience, Eclipse should be able to launch with a particular workspace by double clicking a "workspace description file" -- similar to the MS Visual Studio *.wsp or *.sln files. Detailed Requirements: (1) Export an existing workspace into a Eclipse Workspace Description File (referred to as EWS from now on). Once this has been done, the contents of the actual workspace needs to be kept in sync with the contents of the EWS (that is, the workspace remembers the EWS location until the EWS is deleted). (2) The contents of the EWS is: 2.1. Locations of the .project files, with relative path to the EWS if possible, and information whether the project is open or closed. 2.2. Location of the .metadata area for the workspace. 2.3. Optionally, if selected by the user on export, a transcript of the Workspace level Preferences. Note that this would ideally involve a split of - user level (multi-installation) preferences - installation level (multi-workspace) preferences - workspace preferences 2.4. Optionally, if selected by the user on export, a transcript of the working sets in the Workspace. 2.5. Optionally, if selected by the user on export, a transcript of the Repository locations used by the projects in the workspace. I'm not sure if other state data is needed but don't think so. It should be possible to export multiple EWS files into the same directory, e.g. in order to indicate multiple different selections of projects which different team members might need. (3) Double clicking an EWS opens the Workspace. Initially, a new Eclipse instance can be opened for this; but, related to bug 60289 and bug 245399, it would be ideal if a single Eclipse instance could handle multiple workspaces and the EWS could open inside an already running instance. 2.1. If a .metadata location is found at the place indicated by the EWS, which matches the contents and version in the EWS, it is used. 2.2. Otherwise, the user is prompted where the .metadata should reside (e.g. in order to support read-only file systems). (4) Opening an EWS from a running Eclipse Instance would prompt the user to replace the current workspace with the contents of the EWS, or open a new Eclipse instance with the EWS, or (if bug 245399 is fixed), open the workspace inside the running Eclipse instance. The goal of the EWS would be simplified on-boarding of new users onto an existing workspace that's team-shared by means of some version control system, or otherwise extracted into the file system. EWS files would provide a natural means of grouping projects, which, combined with bug 245399 could become a very powerful concept. Importing a set of projects would become much easier.
As additional constraints, the following features would be interesting: * Importing an EWS file into an existing workspace should override/merge the settings. That way, a team administrator could roll out workspace level changes to the entire team easily. Similar functionality is requested by bug 198569. * The EWS file should be in a user-readable (and editable) format. That way, team members can review the changes being rolled into their workspace before applying an admin-provided change.
Drag & drop of an EWS file into an existing Eclipse workspace would be a nice metaphor for rolling in updated settings (that were obtained by E-Mail for instance). If the roll-in / merge functionality works well, a concept like P2 "watched folder" could also be applied: In the Team environment, the workspace is configured to watch URL x for updates to the workspace. Only admins have write permission into URL x, and can use that URL for rolling out updates to workspace team settings. Watched URL x could also reside inside the workspace, such that team synchronization of the workspace itself would trigger an update of settings.
*** Bug 198569 has been marked as a duplicate of this bug. ***
Good to see you raised this bug Martin. Unfortunately it's been five years. But I think this problem becomes more prevalent with git. And I just ran into this, I did a Pull to get the latest master and we have a huge number of plug-ins. But we don't import them all into our workspaces. We have some that are pretty dead and don't even build any more. Well someone added a new plug-in and it was hard to find. Importing the projects gives you almost an all or nothing feel. Team Project Sets could be the answer but ideally, when you did the git pull, the new projects should get imported automatically. That's where a workspace description file would come in very handy. So +1 from me. I'm dying to get back into this issue and flexible resources in general, so may be able to help out if I get a chance.
