Community
Participate
Working Groups
The usefulness of working sets is limited by the fact they are not team sharable. We will provide support for sharing working set information between team members.[Platform UI]
This is good time to start a discussion on that issue. Some issues came up during some casual chats about it. 1) Working sets can aggregate not only resources or java objects, but breakpoints (markers) and (I assume) any other types of objects. The issue here is that markers and custom objects are not shared now. I think that markers should be shared using a separate mechanism. I would like to hear suggestions and comments. 2) Another issue is how users should configure working sets. Two approaches under discussion are: - import/export mechanism. A user would be able to export selected working sets to a single file, store it in a project and share it. Then another user would just check the project out and use an import working sets mechanism to populate working sets information. - more automated approach. Projects can be configured to share information about their working sets. In this approach, working sets information is stored in one file per project (project preferences could be used too) and the file is shared together with the project. Then when another user checks out the project, information about its working sets is automatically populated basing on the working sets file. Feel free to ask if something is not clear.
> - more automated approach. Projects can be configured to share information > about their working sets. In this approach, working sets information is stored > in one file per project (project preferences could be used too) and the file is > shared together with the project. Then when another user checks out the > project, information about its working sets is automatically populated basing > on the working sets file. > Szymon, we also discussed about the case where a working set stores only a set of files or java packages (resources). Persisting the working set information on a per element ( project) basis is not feasible in such a case ( similarly for breakpoints and other objects). Also, the workingset can store a variety of elements (projects, folders, java packages). The first approach is somewhat similar to how a launch configuration is persisted.
Note that changes to launch configurations are automatically persisted after you have picked the "Shared File" option on the last tab. This is unlike import/export which required an explicit user action to propagate any changes.
Just noticed exporting and importing of working sets provided in Team Project Sets. (Notice the check box on the top 'Export Working Sets' )This works for projects as well as folder, files, packages that are grouped by a workingset. Also, there is the additional support to check out project from CVS if not already present in workspace. Note: the imported workingsets are hidden by default, and have to be manually made visible. I am beginning to see this request as a sortof-duplicate of Team Project Sets. Any thoughts or suggestions?
By "team sharable", we usually mean sharing in a version control system. You can export, but then to share with a team requires several manual steps (export file, send file to team-mate by email or similar, import file). If this information was shared directly in CVS for example, it would be much easier to share across a large team.
Reassigning to new component owners. (I think this one missed the boat for 3.5 as we are well past feature freeze.)
(In reply to comment #6) > Reassigning to new component owners. > > (I think this one missed the boat for 3.5 as we are well past feature freeze.) Yes, unfortunately. Let's shoot for 3.6.
Removing plan keyword as this is not on the Helios plan.
Removed from 3.6. Owners can re-assess. PW
