Bugzilla – Full Text Bug Listing
| Summary: | [api] support populating mylyn context programatically using public API | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | David Green <greensopinion> | ||||||
| Component: | Mylyn | Assignee: | Shawn Minto <shawn.minto> | ||||||
| Status: | CLOSED MOVED | QA Contact: | |||||||
| Severity: | enhancement | ||||||||
| Priority: | P3 | CC: | greensopinion, johan.wannheden, mauersberger, shawn.minto, steffen.pingel | ||||||
| Version: | unspecified | Keywords: | plan | ||||||
| Target Milestone: | --- | ||||||||
| Hardware: | Macintosh | ||||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
I forgot to mention, regarding "Populating the taskscape is of use when a plugin wishes to manipulate the interest for a specific element that is not yet in the Mylyn context": manipulating interest programatically for an element has no effect if it is not yet in the mylyn context. I am interested in this as well. I think that this might be easier using an API on the InteractioncontextManager so that we don't have to manage the propogation, etc. The API I could see is : InteractionContextManager.processInteractionEvent(InteractionEvent.Kind, Object, IInteractionContext) This would allow clients to add objects to the context model without having to know the nitty gritty of how propogation should work. However, this fix would not entirely solve the problem that you are mentioning since InteractionContextManager is internal API, but it would be a lot cleaner I think. What we should be able to do for 2.2 is create provisional API for doing this, and then move that out to public API once we figure out how to make the other parts of InteractionContextManager API. But at least it would hide clients from the implementation details of task context, which will be changing for Mylyn 3.0. David: would this meet your needs? Created attachment 80813 [details]
patch
Attached is a patch to for the API that I outlined, as well as a test.
Created attachment 80814 [details]
mylyn/context/zip
Thanks for the interest/response on this one. So far it looks good, although it's not clear to me how the API should be used. Would the recursive algorithm described above still be necessary, or would it be replaced by this new API call? Also it would be very useful for the manipulateInterestForElement() api call to be made part of the public API as well, since as I understand it it's the only way to make something a landmark once it's in the taskscape. Patch applied. Added test for the non-existing object case, based on your other test. (In reply to comment #6) > Would the recursive algorithm described above still be necessary, or would it be > replaced by this new API call? David: Yes, the goal is to replace the clients from needing to know about any context model algorithms, because those are considered internal and will be changing. Let us know if this method works for you or if you have additional requirements. > Also it would be very useful for the manipulateInterestForElement() api call to > be made part of the public API as well, since as I understand it it's the only > way to make something a landmark once it's in the taskscape. I've added this to the pending changes for 3.0 in the Mylyn Porting Guide. The goal will be to make it possible to create bridges without relying on any internals, or needing to manually create interaction events. This will likely be an API breaking change, and as such will have to happen in one fell swoop after 2.3 (for 3.0). In the meantime I suggest that clients try ask for internal methods of this sort, which will be candidates for API. Leaving this bug open until this method is promoted to API. Great, sounds good to me. Thanks again for your hard work Shawn and Mik. I'll test this one out and let you know if any issues come up. I've now used and tested these APIs with our codebase, and they work really well. Thanks again. Great to hear, thanks David. They will stay as is until the Mylyn 3.0RCs (after EclipseCon) at which point you will need to port to the new APIs. You'll know you need to do this when this bug gets marked resolved. It would be helpful to also load contexts from existing context files without having to know about the handle in the context file. Here is a function that looks into the context file and determines the handle from the first entry:
private String getFirstContextHandle(File sourceFile) throws CoreException {
try {
ZipFile zipFile = new ZipFile(sourceFile);
try {
for (Enumeration<?> e = zipFile.entries(); e.hasMoreElements();) {
ZipEntry entry = (ZipEntry) e.nextElement();
String name = entry.getName();
String decodedName = URLDecoder.decode(name, InteractionContextManager.CONTEXT_FILENAME_ENCODING);
if (decodedName.length() > InteractionContextManager.CONTEXT_FILE_EXTENSION_OLD.length()) {
return decodedName.substring(0, decodedName.length()
- InteractionContextManager.CONTEXT_FILE_EXTENSION_OLD.length());
}
}
return null;
}
finally {
zipFile.close();
}
}
catch (IOException e) {
throw new CoreException(new Status(IStatus.ERROR, ContextCorePlugin.PLUGIN_ID,
"Could not get context handle from " + sourceFile, e));
}
}
Remaining changes will have to wait until 3.1. *** Bug 315016 has been marked as a duplicate of this bug. *** 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 |
Currently the only way to populate the Mylyn context (without using internal api) is via selection events in the UI. It is useful for plugin developers to be able to populate a Mylyn context programatically, however this is only possible when using internal APIs. Populating the taskscape is of use when a plugin wishes to manipulate the interest for a specific element that is not yet in the Mylyn context. This type of feature is useful for MDD tools where the plugin may know more about related/relevant items. For example, an MDD tool could have a "populate Mylyn task context" action enabled for models from which code is generated. Currently our code to populate the mylyn context looks like this: private String populateMylynTaskscape(Object item) { AbstractContextStructureBridge bridge = ContextCorePlugin.getDefault().getStructureBridge(item); String handle = bridge.getHandleIdentifier(item); // make sure that mylyn knows about what we're about to manipulate. IInteractionContext activeContext = ContextCorePlugin.getContextManager().getActiveContext(); IInteractionElement element = activeContext.get(handle); if (element == null || element.getContentType() == null || !(element.getContentType().equals(bridge.getContentType()) || element.getContentType().equals(bridge.getContentType(handle)))) { InteractionEvent event = new InteractionEvent(InteractionEvent.Kind.PROPAGATION,bridge.getContentType(),handle,""); if (activeContext instanceof InteractionContext) { ((InteractionContext)activeContext).parseEvent(event); } else if (activeContext instanceof CompositeInteractionContext) { ((CompositeInteractionContext)activeContext).addEvent(event); } String parentHandle = bridge.getParentHandle(handle); if (parentHandle != null && parentHandle.length() > 0) { // check if should use child bridge Object resolved = null; for (String contentType : ContextCorePlugin.getDefault().getChildContentTypes(bridge.getContentType())) { AbstractContextStructureBridge childBridge = ContextCorePlugin.getDefault().getStructureBridge(contentType); resolved = childBridge.getObjectForHandle(parentHandle); if (resolved != null) { break; } } if (resolved == null) { resolved = bridge.getObjectForHandle(parentHandle); } if (resolved != null) { populateMylynTaskscape(resolved); } } } return handle; } This makes use of some internal API, notably: org.eclipse.mylyn.internal.context.core.CompositeInteractionContext org.eclipse.mylyn.internal.context.core.InteractionContext