Community
Participate
Working Groups
the hyperlink detector should detect "<prefix> <qualified name>". Examples are * See java class foo.bar.Baz, it could be related * See cpp class Foo, it could be related * See file foo.txt, I left some notes there * See task 123, I put a comment there
*** Bug 237974 has been marked as a duplicate of this bug. ***
Created attachment 106214 [details] proto-type for IHyperlinkDetector
Created attachment 106215 [details] mylyn/context/zip
classes hierarchy: *IHyperlinkDetector *ResourceHyperlinkDectector *AbstractResourceHyperlinkMatcher - match hyperlink in the text *JavaReousrceHyperlinkMatcher *CppResourceHyperlinkMatcher *... *ResourceHyperlinkMatcherManager - get all AbstractresourceHyperlinkMatcher, e.g. JavaResourceHyperlinkMatcher, TODO: build an extension point to finish this jobs * IHyperlink *JavaResourceHyperlink *CppResourceHyperlink *... The basic idea is ResourceHyperlinkMatcherManager returns all AbstractresourceHyperlinkMatcher, with which ResourceHyperlinkDectector detects the hyperlinks. I am not sure whether its a good idea to have this design, but it can be extended to detect all the hyperlinks by extending AbstractresourceHyperlinkMatcher, e.g. TaskResourceHyperlinkMatcher for all task hyperlinks (replacing TaskHyperlinkDetector?).
features included in the latest patch of bug 237831
About a functional point of view, it would be fantastic to have hyperlinks shortcut from the task to the related source code within the WorkingSet whenever a java class, method, field is identified with a full qualified name or not. Also, I think that it would be interesting to have a regexp expression (that could be customized) to extract information required to make the hyperlink. I mean some time some tools display location in the code that could be an XPath in a XML file instead of a source line code (like [/usr/alfred/code/sample.xml]:/catalog/animal/dog) and to open the file at the right location, it could be good to extract the filename and the Xpath and then process the information to open the file on the node. I thought about this kind of customization because such feature depends on your development environment and I'm not sure anyone will develop a plugin that fit its needs.
(In reply to comment #6) > About a functional point of view, it would be fantastic to have hyperlinks > shortcut from the task to the related source code within the WorkingSet whenever > a java class, method, field is identified with a full qualified name or not. yup, the initial implementation will only display links that exist in the workspace, e.g. java class foo.bar will not be displayed as a link since the workspace does not contain foo.bar > Also, I think that it would be interesting to have a regexp expression (that > could be customized) to extract information required to make the hyperlink. > > I mean some time some tools display location in the code that could be an XPath > in a XML file instead of a source line code (like > [/usr/alfred/code/sample.xml]:/catalog/animal/dog) and to open the file at the > right location, it could be good to extract the filename and the Xpath and then > process the information to open the file on the node. great idea, Steffen, would it be possible to support such flexibility?
Owen, I am getting conflicts when I try to apply the patch and it is quite big. Could you recut it against head and make a patch that is limited to the Java hyperlink detector?
Created attachment 107129 [details] Only the hyperlink detector Please refer to comment #4 for class hierachy. Its big because it includes detecting other resource, e.g. cpp.
Created attachment 107130 [details] mylyn/context/zip
sorry the hierarchy is changed to the following: *ResourceHyperlinkExtensions - manager *ResourceHyperlinkExtensionReader *IResourceHyperlinkExtension *AbstractResourceHyperlinkExtension - with various helper methods *JavaResourceHyperlinkExtension *CppResourceHyperlinkExtension *... * IHyperlink *JavaResourceHyperlink *CppResourceHyperlink *... *IHyperlinkDetector *ResourceHyperlinkDetector
> > I mean some time some tools display location in the code that could be an > XPath > > in a XML file instead of a source line code (like > > [/usr/alfred/code/sample.xml]:/catalog/animal/dog) and to open the file at the > > right location, it could be good to extract the filename and the Xpath and > then > > process the information to open the file on the node. > > great idea, Steffen, would it be possible to support such flexibility? It's definitely an interesting idea. It tends to be difficult to provide a good UI for configuring advanced settings such as regular expressions. Alfred, it should be fairly straight forward to implement a plug-in with a custom hyperlink detector for your specific syntax. The patches on this bug are a good example how to do that.
(In reply to comment #12) > > > I mean some time some tools display location in the code that could be an > > XPath > > > in a XML file instead of a source line code (like > > > [/usr/alfred/code/sample.xml]:/catalog/animal/dog) and to open the file at the > > > right location, it could be good to extract the filename and the Xpath and > > then > > > process the information to open the file on the node. > > > > great idea, Steffen, would it be possible to support such flexibility? > > It's definitely an interesting idea. It tends to be difficult to provide a good > UI for configuring advanced settings such as regular expressions. > > Alfred, it should be fairly straight forward to implement a plug-in with a > custom hyperlink detector for your specific syntax. The patches on this bug are > a good example how to do that. > OK, I understand that it could be difficult to do something generic. As I'm pretty new with MyLyn, for what I already read, I need to use the Rich Text editor, right? Because the tool that I'm using report issue from a web interface and I was thinking that I could use the Generic Web Connector for that. But I discovered that it is running the OS browser to display the task details, so HyperLink from a web page to Java object is not an option, right? So, probably the best solution is to change the tool to get a XML document instead of a web page. If I'm still right with my assumptions, what could be the best sample of such Rich Text Editor that could inspire me to build my own from an XML document? Thanks for your help.
Yes, the hyperlinking only works in SourceViewer widgets which are used by the richt text task editor. You are right that the Web Templates connector (formerly Generic Web connector) uses a browser which does not support Eclipse's hyperlink detection. You would have to implement a connector for your bug tracking system to get the tasks show up in a rich editor. The Trac or Bugzilla connectors are good examples of how to do that. Which bug tracking system are you using?
(In reply to comment #14) > Yes, the hyperlinking only works in SourceViewer widgets which are used by the > richt text task editor. You are right that the Web Templates connector > (formerly Generic Web connector) uses a browser which does not support > Eclipse's hyperlink detection. > > You would have to implement a connector for your bug tracking system to get the > tasks show up in a rich editor. The Trac or Bugzilla connectors are good > examples of how to do that. Which bug tracking system are you using? > Well, it is not really a tracking system. It is a product that measure the quality of your application through static analysis. It detects violation in your code that could involve several technologies and/or several files. So it means that fixing an issue may involve several files and people. So, I was thinking that the MyLyn features could be interesting to address such issues because the advantages are the context sharing and the commit of all files that are involved with a predefine template for traceability. The product is called CAST.
Owen, could you attach a patch to this bug that has the ResourceHyperlinkDetector registered for the task editor and the default hyperlink detector. Please provide a patch against the current CVS that does not contain any other unrelated changes.
Created attachment 109210 [details] the rest of the patch * DefaultResourceHyperlinkExtension group * ResourceHyperlinkExtension * TaskEditorDropTarget
Created attachment 109211 [details] mylyn/context/zip
A doubt: in DefaultResourceHyperlinkExtension.isResourceExistsis(..), it cannot detect hyperlinks like "org.eclipse.mylyn.monitor.core/META-INF/MANIFEST.MF", which should do since I am using ResourcesPlugin.getWorkspace().getRoot().findMember(new Path(resourceName), true) to get the IResource. Maybe it does not recognize META-INF as the source folder hence not a member of the project. But the strange thing is it can recognize something like org.eclipse.mylyn.monitor.core/build.properties. Please try dragging a MANIFEST.MF and a build.properties to see the difference.
btw, you need to uncomment the line of TaskEditorDropTarget.addDropTargetSupport(viewer) in ExtensibleRichTextAttributeEditor.configureAsTextEditor(..) to run the patch.
Created attachment 109214 [details] scrennshot of dropping a set of elements into the new comment section
Cool stuff! I have merged the patch except for the drop target. I could not find the line to enable the drop support for the viewer. Please attach a patch that adds the missing bits for drag & drop support to bug 237831. It would be great if you would add a list of the supported hyperlink prefixes to your SoC wiki page and maybe a screenshot. (In reply to comment #19) > A doubt: in DefaultResourceHyperlinkExtension.isResourceExistsis(..), it cannot > detect hyperlinks like "org.eclipse.mylyn.monitor.core/META-INF/MANIFEST.MF", Please attach a failing test case for that scenario to bug 241600. The java class org.eclipse.mylyn.context.tests.support.ResourceHelper has examples how to create test projects from JUnit test cases.
