Community
Participate
Working Groups
If a user has a large number of projects (> 50) it becomes more difficult to navigate the projects in Eclipse. For example, to find specific files or classes in the 'Package Explorer' or 'Navigator' views. If a logical group could be defined by a user this would improve the navigation. The purpose of a group would be purely for navigational presentation purposes in Eclipse. For example, a 'BatchTestCases' group could be defined to include a 'BatchA' project and a 'BatchB' project. Then, in the 'Package Explorer' or 'Navigator' view (for example), the user could see something like the following: - BatchTestCases - BatchA .project ... - BatchB .project ... In order to improve the navigation further, a related feature is the ability to then nest this grouping capability. For example, the user could see something like the following in the 'Package Explorer' or 'Navigator' view (where '(G)' indicates a group, and '(P)' indicates a project): - TestCases (G) - BatchTestCases (G) - BatchA (P) - BatchB (P) - UITestCases (G) - UIA (P) - UIB (P) - OtherTestCases (P) The following existing features are not sufficient to improve the navigation: 1) Working Sets Problems: a) Working set definitions are stored in the workspace. An interchange format and the associated tooling to support an interchange format do not exist. Hence, the working sets need to be defined each time a new workspace is created. b) If you have a working set enabled and you introduce an error outside of the working set, the error is not visible until the working set is disabled unless you have the 'Tasks' view filtering set to 'On any resource'. Having the 'On any resource' option selected introduces too much noise to the 'Tasks' view. 2) Defining multiple source folders under Java related projects, instead of multiple projects under logical groups. Problems: a) Source folders do not have their own '.classpath' and '.project' files. Hence, dependencies between the source folders can not be setup and enforced.
Improve working sets by making them exportable (to another workspace). Look into error messages that are being filtered out (i.e. new 'Problems' view).
1a, exporting/importing working sets is covered by bug 30687. 1b, we could prompt when a new error is generated that is not shown with the current task filter. This would be useful independent of working sets although working sets would be one possible way to implement this. Entered bug 37235 for this. You envision the "navigation only" logical groups work across plugins (UI and JDT). This means we would need to add UI API. Should these groups also be managed by a repository provider? If so this support needs to go into Core and not UI. It would also be more heavyweight in that case. I.e., it likely shouldn't just be a logical grouping.
Added bug 37389 for nesting working sets and bug 37390 for a graphical indicator in the tasklist (tab) to let the user know that there are problems she is not seeing.
John, did you enter bug 37389 in response to the "logical groupings"? I don't think that would address the original concern. It would allow groupings of working sets but would not change the underlying project/folder based resource structure.
bug 37389 is in response to the logical groupings. The user doesn't want to change the underlying project/resource structure (except to make it more fine grained); they want to be able to look at various subsets of the structure. The original request to show the structure in all of the navigation views was perceived to add to much "noise" to the front of all presentations; therefore the idea of using nested working sets as a way of describing the myriad logical groups of projects.
Keeping this bug open to verify that the referenced bugs adequately support this scenario once they are fixed.
Reassigning to Nick since he is taking ownership of Navigator
The original idea here (support for groups that can contain projects as children) seems appealing. It would have several usability benefits over working sets. - Groups would appear in the package explorer / navigator just like folders and projects. This makes the group structure easily visible in the UI. - Users can see which group they are browsing by glancing at the package exporer. In contrast, the current working set is only shown if you open a dropdown menu. - Groups could be edited using drag-and-drop and other well-understood tree editing operations, in contrast to working sets which use a specialized UI that is hidden within several modal dialogs. - It would be possible to see the contents of two groups at once, allowing users to easily move projects and files between groups (unlike Working Sets, which can only be viewed one-at-a-time). - Users can switch between groups using tree selection. Working sets require at least 4 mouseclicks. - Groups can be browsed and edited in a non-modal UI. Groups are clearly less flexible than working sets since they cannot control inclusion below the resolution of individual projects, but they would seem to be more useful for the task of organizing large workspaces. Groups (or something similar) could also have some interesting uses for revision control. If groups were stored in CVS as a list of projects and their version tags, you could create a group that serves the same function as the org.eclipse.releng project. That is, you check out the "Eclipse SDK" group with the revision tag I20031203, and you get the correct version of all the plugins that went into the Dec 3 integration build of Eclipse. "groups" don't really need to be a new concept. They could simply be a new type of project that is permitted to contain other projects.
I think this might be related to the work Serge is doing on resource groups. In any case, it's not a navigator/CNF issue without the underlying support.
I don't think that Virtual Folders can help here. IMO we need nested projects capability and top-level virtual containers (maybe just virtual projects) to fix this issue. But indeed this looks like a core.resources issue.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the stalebug whiteboard tag.
