Community
Participate
Working Groups
Mylyn's task working sets may contain projects as well as Mylyn queries. The package explorer working sets configuration dialog only lists these working sets if they contain projects only. Once a task working set is made visible it is possible to add queries to it and it will remain to be visible. It would be better if the behavior was consistent and task working sets would always be selectable (i.e. if they contain at least one project). The corresponding filtering code checks if all elements are adaptable to IProject and not just at least one: WorkingSetConfigurationDialog$Filter.isCompatible(IWorkingSet) line: 117 (The work around to make a task working set visible in the package explorer is to remove all queries from it and add at least one project, select it in the package explorer working set configuration dialog, and then add the queries back to the working set.)
Benno, looks like an easy fix on our side. If not move back to inbox.
I want to give this to Martin. Yes it would be an easy fix, but I think Martins vision is, that the PE shows Java elements and resources only. It is not a common navigator like the project explorer. But I agree that the behavior is not consistent. Mik, another solution/workaround for you would be to adapt a mylyn query to IProject.
I am not sure that there is a sensible mapping for adapting queries to projects. Queries are associated with repositories and tasks both of which are not linked to resources. The suggested change would not cause queries to show up in the package explorer (which I agree is not desirable) or change the way non-resource elements in working sets are currently handled. It would merely allow the selection of working sets with non-resources elements in the configuration dialog. I am afraid the alternative would be to drop a working sets once a non-resource element is detected which would effectively disable support for task working sets in the package explorer. Needless to say I would prefer the current behavior to that :).
(In reply to comment #3) > I am not sure that there is a sensible mapping for adapting queries to > projects. Queries are associated with repositories and tasks both of which are > not linked to resources. The suggested change would not cause queries to show > up in the package explorer (which I agree is not desirable) or change the way > non-resource elements in working sets are currently handled. It would merely > allow the selection of working sets with non-resources elements in the > configuration dialog. Currently you can only select a WS if it contains only object adapted to IProject, with the proposed change you could only select a WS if it contains at least one object adapted to IProject, which is better. But I think the user will still not understand why he can select some task working sets (those containing at least one IProject) and some not. As a user I would be frustrated by such a UI thinking: Damn, where has my task working set gone! > I am afraid the alternative would be to drop a working sets once a non-resource > element is detected which would effectively disable support for task working > sets in the package explorer. Needless to say I would prefer the current > behavior to that :). You would still need to do that, once only non-resource elements are detected.
While ago I've been arguing the idea of heterogenous working sets such as Mylyn's task working set implementation and my original implementation for those didn't had resources/projects stirred in, but Mik had his reasons to change that. Now, there is a mapping from project back to Mylyn's task repository, so it should be possible to create a reversed mapping and probably adapt to IProject, though that seem like a hack, trying to stich apples and oranges (resources and tasks) within the same working set.
Created attachment 99488 [details] patch The patch adds a new filter check box 'Hide non-Java working sets without projects', which is enabled by default. This would need some extensive testing. Question to Mylyn, how important is this feature? If not super important then I would suggest we release and test that in 3.5.
My sense is that most users don't know that it is possible to make task working sets visible in the package explorer and therefore won't run into the current inconsistencies. I am okay with postponing changes until 3.5.
Thanks Steffen, setting the target to 3.5 then.
I looked at the proposed solution and am not very fond of it. Did I understand it correctly that it would be OK for you to show the Task working set if at least one adaptable is in there that adapts to IProject? If so, this is now fixed in HEAD. Please give it a try.
.
I have verified that this works with 3.5M7. Task working sets are now displayed in the selection dialog if they have at least one project. Thanks!
Great!
