Community
Participate
Working Groups
It would be handy to be able to search trough Mylar contexts by class or method name (perhaps using the same options as Java search), so it would show artifacts (classes and methods) and tasks where those artifacts appear.
I've wanted this for some time too :) There's some interesting overlap between Active Search, Mylar's dynamic search scope for the active context, and this. I hope to get to this after 0.5.1 one goes out and will post additional thoughts here.
The major difference from active search and Mylar's dynamic scope is that this should search trough all tasks and even should allow to search trough archived tasks. So, it is more like BugZilla search and I'd say there is some overlap to what Hipicat is trying to do...
I consider the fact that we only keep the active task context loaded an implementation detail, albeit a pretty big one ;) But for Mylar 0.6 chances are that this sort of search will feel similar to what you're suggesting, with scopes something like context - active task contexts - all local contexts - all repository contexts One annoyance is that Bugzilla doesn't yet support searching attachments so we may need to ask for that.
Advanced feature, likely won't make it into 1.0 as it will require us to maintain the context dependency structure in order to avoid loading in every context.
It would be easier to implement it, if we could open context without activating the task. It seem related to previewing contexts without activation.
Yup, that would provide a mechanism to do a search by activating each task context without materializing it in the workspace (bug 174658). It might make more sense to do this with a type dependency style index, which would also support fixing bug 112721.
It would be easier if we could open context *without* activating the task. It seem related to previewing contexts *without* activation. I still consider it a huge drawback that task context require all referenced resources to be present in the workspace. Activating task context will essentially force loading models for all referenced resources into memory and can also trigger additional plugin initialization. Both aren't really fun, as we saw workbench blocking during context init.
(In reply to comment #7) > It would be easier if we could open context *without* activating > the task. It seem related to previewing contexts *without* activation. I was making a distinction between context activation and materialization, but we're talking about the same thing. > I still consider it a huge drawback that task context require all referenced > resources to be present in the workspace. Activating task context will > essentially force loading models for all referenced resources into memory and > can also trigger additional plugin initialization. Both aren't really fun, as we > saw workbench blocking during context init. In terms of the current design, activating the task context does not require any bridge activation (and hence downstream plug-in activation). When something in the Focused UI asks for a handle (e.g. a Java project is asked whether or not it should be filtered) activation is required. When I next iterate on the context model I will verify that this design still matches the implementation.
(In reply to comment #8) > In terms of the current design, activating the task context does not require any > bridge activation (and hence downstream plug-in activation). When something in > the Focused UI asks for a handle (e.g. a Java project is asked whether or not it > should be filtered) activation is required. Wouldn't search have to ask for the handle for each context entry? I am thinking of including context references when searching using something like Ctrl-Shift-G. For example, Spring IDE now neatly shows bean declarations referencing given class, it would be also interesting to see the tasks that reference these classes. Are we still talking about the same use case?
Looking up handles doesn't require a connector. So for something like Ctrl+Shift+G the process would be: 1) Connector looks up the element and generates its handle 2) Context Core looks for all contexts with that handle and retrieves them. 3) Display results (e.g. could just show the tasks, activate those contexts without materialization, have some semantic thumbnailing of contexts, etc.)
That may work, but what about cases when handle can't be looked up? I.e. when searching by non qualified class name, pattern or incomplete matches (like packages renamed from mylar to mylyn)...
*** Bug 200763 has been marked as a duplicate of this bug. ***
A use case for this feature: A user is reviewing the code and found something special or some code is hard-to-understand in a method, he/she may think this part of code is for fixing or implementing a bug or feature, so going through the bug/feature info will help understand this part of code. Then she should be able to right click this method and select "Associated bug/features" item in "Package Explorer" or "Outline", the associated bug/features should show up.
Need to defer this since for 3.0 we're focusing on API enhancements and UI finesse instead of new features.
Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn
