Community
Participate
Working Groups
Our aim is to generate the whole Workspace infrastructure from a UML-Case Tool. We would like to use eclipse as an IDE for customizing source files and maintaining generated projects. Right now this is possible with JBuilder, but not with eclipse for some reasons. One of the reasons belongs to the provided workspace working set. Because we are dealing with very large projects and a lot of generated files, it would be very helpful, if we could make use of extended and extern configurable working sets. Perfect would be a hierarchy of working sets: - One working set per workspace - One working set per project (rules in these working set overwrite rules in the global workspace working set) - Make working sets extern configurable (like .classpath or .project files), so that they can be imported together with an extern project. Regards, Mark Evertz
We used to have a global workbench working set. However, we changed this to per view working sets since very few views support working sets. I don't quite see the advantage of per project working sets. This seems very fine grained and would complicate working sets from a user point of view. Many users already find the current UI for selecting one working set for the Navigator too complicated Do you have a scenario where such a feature would be useful?
Thanks for answering, I think that a more fine grained approach doesn't necessarily leads to a more complicated one. Think of my inheritance like approach I mentioned in my first posting. If you want to make use of a working set per workspace (should be the default), everything looks and feels like before. Only in case of special requirements properties of the default can be overwritten by specialized working set properties of lower workspace elements (e.g.projects). There's no need to edit them if you don't use them. In our special case, we generate projects from uml case tools, thus leading to different project types from the eclipse point of view. Think of uml case tools usually providing different packages created during the developement process: Use cases, class views, component view. These packages should be imported deperately in eclipse for further customization. We already provide JBuilder support, where bundles of file types can be very fine grained specified, but we see the advantages of eclipse , of course and would like to migrate. These projects containin different file types. In some project types we want to make them viewable in others not, even in the same perspective. To edit such a hierarchy shouldn't take place, where you choose the working set on the GUI, of course :-)
Given that working sets are not even global in 2.0 I doubt this type of fine grained support can happen in 2.1. Presently each view implements working set filtering separately. Even if you could have working sets associated with projects the views would still need to support this. Did you consider alternatives? For example you could set viewer filters on the Resource Navigator tree viewer to filter unwanted resources depending on the selected project. See IResourceNavigator.getViewer and StructuredViewer.addFilter. Since your scenario seems to be somewhat dynamic (will users create new use cases etc. in Eclipse?) filters seem more appropriate than working sets. Perhaps even custom viewers would be appropriate. E.g., a use case view, component view, test view.
I strongly recommend investigating the use of custom views and/or viewer filters. I just don't see how working sets can support a usable solution.
