Community
Participate
Working Groups
In the properties dialog of "Task Repositories" view we set up the url, then can internally refer to links in the issue tracking system, e.g. typing "refer to [[WikiText]] in the wiki" in the Bugzilla task editor, it generates links to WikiText in Eclipsepedia. This bug may relate to bug 237500
this bug can start after bug 237500 is done
This is similar to what has been requested on bug 218835. Is there a common abstraction that could be used to implement hyperlinking that is specific to a particular environment?
markup languages such as MediaWiki, TracWiki and Confluence define special syntax to refer to 'internal' links. The markup language parser is able to detect these and will be able to generate the appropriate hyperlinks if the parser is configured correctly. For example, from the MediaWiki syntax guide you can write: Here's a link to the [[Main page]]. the corresponding rendered text looks like this: Here's a link to the Main page. where 'Main page' is a hyperlink to http://en.wikipedia.org/wiki/Main_page
can this task start, based on the prototype in bug 237500? My idea is to contribute a menu that can show up a input dialog for the url of the issue tracking system
Is it possible to intercept the links and redirect to the appropriate page?
(In reply to comment #5) > Is it possible to intercept the links and redirect to the appropriate page? I am not sure how it would be possible to intercept the links. Please note that issue tracking system and wiki system (e.g. eclipedia) are two different systems. A scenario could be typing internal links in bugzilla (e.g. Here's a link to the [[Main page]]) then a link to eclipedia will be generated. The goal is to NOT explicitly write the links then it can generate the links to the default wiki system. Therefore we need to insert and save the url of the wiki system set before hand.
You may want to take a look at org.eclipse.mylyn.wikitext.mediawiki.core.MediaWikiLanguage.setInternalPageHrefPrefix(String) as it is an API for doing exactly what Owen is describing. This API could easily be called by the TaskEditorExtension when creating a source viewer or editor.
I am planning to add an optional attribute *wikiURL* to repositoryAssociation in taskEditorExtensions.exsd, when TaskEditorExtensions.addRepositoryAssociation is called also adding such optional attribute to a map called wikiURLByConnectionKind. This might make as few changes as possible. Any thoughts?
I am not sure if it makes sense to define a URL for all repositories of a particular kind. Isn't the URL something that should be set per repository, e.g. /wiki.eclipse.org for bugs.eclipse.org?
(In reply to comment #9) > I am not sure if it makes sense to define a URL for all repositories of a > particular kind. Isn't the URL something that should be set per repository, e.g. > /wiki.eclipse.org for bugs.eclipse.org? It totally makes sense to have a URL for every repository instance :). But are there any ways to make sure the wiki URL does not tangle with existing repository settings if we do this? It might be a good idea to grouped with other WikiText settings, e.g. the markuplanguage.
(In reply to comment #10) > (In reply to comment #9) > > I am not sure if it makes sense to define a URL for all repositories of a > > particular kind. Isn't the URL something that should be set per repository, > e.g. > > /wiki.eclipse.org for bugs.eclipse.org? > > It totally makes sense to have a URL for every repository instance :). But are > there any ways to make sure the wiki URL does not tangle with existing > repository settings if we do this? It might be a good idea to grouped with other > WikiText settings, e.g. the markuplanguage. I mean all concerns might be a good idea to go TaskEditorExtensions
(In reply to comment #10) > (In reply to comment #9) > > I am not sure if it makes sense to define a URL for all repositories of a > > particular kind. Isn't the URL something that should be set per repository, e.g. > > /wiki.eclipse.org for bugs.eclipse.org? > > It totally makes sense to have a URL for every repository instance :). But are > there any ways to make sure the wiki URL does not tangle with existing > repository settings if we do this? It might be a good idea to grouped with > other WikiText settings, e.g. the markuplanguage. > The setting can easily be grouped together with other things in the UI. It doesn't belong in taskEditorExtensions.exsd.
Yes, we can do the grouping in the UI. For now you could contribute an entry to the "Task Editor Extension" submenu, e.g. "Wiki URL", that shows an input dialog for the URL.
Created attachment 106880 [details] contributed an entry to the "Task Editor Extension" submenu All can be shipped to Mylyn's repository setting page when its ready. One question: Would it be a good idea to support internal links for all markup languages, even for those which do not have such syntax, e.g. Textile? I myself do find it convenient to have such features.
Created attachment 106881 [details] mylyn/context/zip
What do you mean by internal links? Something like anchors or links to other comments?
(In reply to comment #16) > What do you mean by internal links? Something like anchors or links to other > comments? sorry for the confusion. What I meant is the links to the wiki system. The term "Internal link" is quoted from http://www.mediawiki.org/wiki/Help:Links . It means a link to the system itself. Quoted from my proposal "Wikis and issue tracking systems are two of the most popular software management systems used in open-source communities and companies. Typically, developers keep track of reported software bugs in their work using bug tracking systems such as Bugzilla and at the same time, maintain their knowledge base using wikis such as MediaWiki. Real-world examples are not uncommon [1, 2, and 3]" [1] Mozilla, https://bugzilla.mozilla.org/ and http://wiki.mozilla.org/Main_Page [2] Eclipse, http://bugs.eclipse.org/bugs/ and http://wiki.eclipse.org/Main_Page [3] Sun Microsystems Inc, http://wikis.sun.com/dashboard.action and http://bugs.sun.com/ Therefore, what I meant by "Internal link" is the links to an open-source community or company's knowledge base (e.g. the wiki system). As far as I know, Tasktop also redirects all the internal links in its Bugzilla to Wikipedia, right?
the concept just switches from web pages (e.g. a page in Bugzilla) to offline editing task editors
another example is Trac which combines wiki and issue tracking itself, http://www.hosted-projects.com/trac/TracDemo/Demo/wiki/WikiFormatting#Links
(In reply to comment #14) > Would it be a good idea to support internal links for all markup languages, > even for those which do not have such syntax, e.g. Textile? I myself do find it > convenient to have such features. > We should only support internal links for those repositories that support it.
> We should only support internal links for those repositories that support it. That sounds right. Custom syntax extensions could be hard to remember. We could consider a custom hyperlink detector for references to a wiki, e.g. "wiki Page" (bug 239087).
Owen, what is the status the patch? Can you recut it against cvs head?
Created attachment 110026 [details] recut the patch the patch contributed a submenu to the "Task Editor Extension". I am afraid its impossible to set the internal link pattern at this point, unless the WikiText component provides API to do that, e.g. expose MakrupLanguage.setInternalLinkPattern(..) to AbstractTaskEditorExtension
Created attachment 110027 [details] mylyn/context/zip
Created attachment 110028 [details] screenshot of the contributed menu
This setting will only work for those repositories that support internal links to wiki pages from tasks (issues/bugs). For WikiText, this can only be for repositories that use TracWiki, MediaWiki or Confluence markup languages (Textile has no internal link syntax). I'm not aware of any task repository that uses MediaWiki syntax. Some relevant links: * http://confluence.atlassian.com/display/JIRASTUDIO/Creating+Links * http://trac.edgewall.org/wiki/TracLinks If the setting is made and stored in the @TaskRepository@, then the @MarkupTaskEditorExtension@ can configure the @MarkupLanguage@. This is why the @TaskRepository@ is passed to the @MarkupTaskEditorExtension@ in the first place -- so that the extension has access to settings of the @TaskRepository@. I recommend changing the patch to set the internal link pattern as an attribute on the @TaskRepository@ using @TaskRepository.setProperty(String,String)@.
That sounds good to me. Owen, the best place to define the key for the property is probably in AbstractTaskEditorExtension.
Created attachment 110032 [details] patch based on Owen's work that sets the attribute on the task repository how about something like this? The editor extension and contribution item communicate via the repository settings. the property name constant should of course be moved somewhere appropriate.
(In reply to comment #28) > Created an attachment (id=110032) > patch based on Owen's work that sets the attribute on the task repository > > how about something like this? The editor extension and contribution item > communicate via the repository settings. > the property name constant should of course be moved somewhere appropriate. Looks great! in reply to "For WikiText, this can only be for repositories that use TracWiki, MediaWiki or Confluence markup languages (Textile has no internal link syntax). I'm not aware of any task repository that uses MediaWiki syntax." Any APIs to get a list of extensionIds that support internal link pattern? Otherwise I might have to hard code which repositories can run the action
The enablement of the feature will depend on the selected WikiText extension rather than the selected repository. David, is there a way to tell if an extension supports this? Otherwise it could be okay to leave it enabled for all.
(In reply to comment #30) > David, is there a way to tell if an > extension supports this? Otherwise it could be okay to leave it enabled for > all. This could get complicated. For example, how would we handle the situation where the attribute was set, then the markup language changed to something that doesn't support the setting? The setting would have to get cleared when the markup language was changed. Perhaps we should just leave it enabled for all.
Excellent! Thanks Owen and David. I have applied the patch with minor modifications: I moved the constant for the properties key to the java class AbstractTaskEditorExtension (wow, the completion worked!).
Nice, thanks!
