Mylyn/SOC/2007/Mylyn Plug-in for DrProject
Student: Xiaoyang Guan
Mentor: Greg Wilson
Most professional programmers now use an IDE like Eclipse, and many Computer Science students have also adopted it. Most professionals and open source developers also rely on web-based project management portals such as SourceForge, Jira, and Trac. These are still not commonly used in classrooms, but projects like DrProject are working to change that. DrProject is a fork of Trac that has been customized for classrooms use; it is now being used in several courses at two universities, and is being evaluated by several others.
At present, most developers have to switch from their IDE to a browser in order to file or view bugs, edit wiki pages, and so on. One prominent exception is the Mylar project, which has been working since 2003 to provide a view inside Eclipse that allows programmers to see and update shared information, particularly from bug tracking systems like Bugzilla. The aim of this project is to bring that capability into the classroom by using Mylar to create a bridge between DrProject and Eclipse. This integration will allow students to perform the management on the repositories in DrProject directly in Eclipse.
In addition, as an enhancement to Mylar, this project will provide wiki integration. This involves providing mechanisms for rich editing and viewing of task repository comments in wiki format, potentially adding wiki editing.
The first primary goal is to support wiki formatting in task editor. This will be carried out based on the current Trac connector in Mylar. (see bug#184904)
- Provide a HTML-based widget for rendering wiki-formatted text. This might involve writing a simple wiki rendering engine as a prototype. Limitation of HTML is that we can’t link to structured elements within Eclipse (e.g. Java elements in stack traces, other tasks). [EK that is not necessary true. if you create hyperlinks then you can navigate to the appropriate elements]
- Provide a rich/styled text widget that renders the basic wiki syntax, provides rich editing, but has wiki formatting underneath so that the Trac server gets wiki text. Benefit is that this can fully link to elements within Eclipse.
- Make it easy to paste links to Mylar tasks within wikis. This could be done by having the Copy Details action take templates similar to Mylar’s Commit Comment Templates, and specify a good default template for wiki formatting, e.g. [<url> <id>: <summary>]
- Provide button widgets for automatically inserting wiki markup characters in input text, the same as those in the web-based interface, and a preview button that renders the ticket preview. This provides similar user experience as using the web-based interface. [EK those should be regular actions that can be bound to shortcut keys and shown on some toolbar]
- Provide content assistant similar to that in Eclipse Java IDE that facilitates editing wiki markup syntax.
Wiki-formatting is allowed in ticket description and comments sections. The description of an existing Trac ticket is editable, the same as the new comment section; while existing comments are read-only. In the editable sections, a new browser widget and a preview button will be added besides the current StyledText widget for editting the raw wiki text. In the read-only sections, the current StyledText widget will be replaced by a browser widget to present the text in HTML format.
Formatting the wiki text into HTML is done by calling the wiki.wikiToHtml function provided by the Trac XmlRpcPlugin. To minimize the time for opening an existing repository task, the HTML formatted presentations of the current description and existing comments will be cached offline. A round-trip to Trac repository to format the modified description and new comment only occurs when the user clicks the preview button, and this operation is run asynchronously in a separate thread from the UI thread.
Note: to build a client-side wiki text formatter in Eclipse has the follow problems, suggested by Greg Wilson :
#1. Most wikis format PotentialLinkText differently depending on whether the page being linked to actually exists or not, but the only way to know that is to query the database where the wiki pages are stored. The client *could* cache that information, but that would still leave: #2. Most wiki systems have some sort of macro facility. In Trac, for example, you can register bits of Python code, then invoke them to do things like list all the wiki pages, provide backlinks, etc. Macros usually pull stuff out of the database. I can't see any way to do this client-side (unless we include interpreters for the major scripting languages and a DB proxy in the wiki formatter, which I think is out of scope ;-). Macros are used often enough, in enough wiki systems, that I don't think they can be left out; if we're going to round-trip to the server to execute macros, we might as well do one round trip to format the whole page, no?
See bug 191114 for the implementation for the ticket description.