Community
Participate
Working Groups
Supporting multiple servers is key for people working on multiple projects. But to prioritize this it would be good to know whether these people typically use multiple workspaces.
IMHO it would not be safe to assume multiple workspaces or even multiple projects for multiple prividers. Eclipse is good example why. Many developers working on eclipse use eclipse.org as an upstream source for their own product. This type of situation lends itself to having a bug provider for their own product as well as one for the upstream provider. In addition, components of their project could rely on other third party sources which have their own bug providers (like Tomcat or Ant in eclipse). So, a single project in a workspace could potentially lead a developer to having multiple providers associated with that project.
Good points. Another Mylar developer has already reported the need for this too, so I'm raising priority. I'm raising priority on it, but please note that that we probably don't have the resources to do it quickly.
(In reply to comment #2) > Good points. Another Mylar developer has already reported the need for this > too, so I'm raising priority. I'm raising priority on it, but please note > that that we probably don't have the resources to do it quickly. The following is proably should go into separate issues, but I'd like clarify it first. I wonder if there are any plans to add support for non Bugzilla repositories? Another thing to consider is how to expose repository parameters to other Eclipse components. For example there is an enhancement request for CVS plugin to provide link to the bugtracking system based on some matching with commit comments. Note that other team providers may already have some mechanisms to reference bug repositories. E.g. Subclipse is storing bugtrack repository params in module properties and using this to provide a hyperlink from the commit comment text.
The idea is to allow any repository plug-in to extend the Task List with it's own repository. So org.eclipse.mylar.bugzilla.ui contributes all the bugzilla functionality to org.eclipse.mylar.tasklist via extension points. Although we don't have the resources to do other repositories now, we will actively support any one wanting to do so, either as a contribution to Mylar or as a seperate project. I really like that feature of linking up commit commits comments to bugs. Could you create a new report where describing what you would like to see? Fyi, in the next release we already have support for making a comment like "see bug 123" hyperlink clickable to open the report.
Thanks Mik. I'd like to try to add some support for JIRA bug tracking system and wonder if you can give me some pointers about these extension points.
By the way, can somebody clarify what is the current vision how multiple bug providers going to be configured? For instance I have projects in my single workspace that are using 3 diferent bugzilla repositories (eclipse.org, tigris.org, dev2dev.bea.org), 2 different JIRA repositories, and several - SourceForge. I like repoitory managent UI in "Bugzilla Integration Plugin for Eclipse 3.1" http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-vcm-home/docs/online/bugs-plugin/index.html There is a wizard that allows you to choose bug provider type and then add new bug repository. That UI is actually similar to the wizard used to create new "Synchronize...". Perhaps Mylar should acquire that Wizard and provide new view that will show all registered bug repositories (somehow similar to CVS and SVN repositories). To start with this view can show just list of repositories and can be later extended to allow drilling down (like above bugzilla plugin does). Tasklist actions add, create new, add query related to bugzilla should be generalized and perhaps should use some wizard which will allow to choose bug repository that already registered in repositoris view and then fall down to the panels specific for selected provider type. Refresh action should work for all providers. I guess that you already know that his plugin had been forked and extended with several interesting features: --- The plug-in now includes support for bugzilla 2.18 as well as various new bits of functionality such as integrated querying, and applying a patch from a bugzilla comment directly to a workspace. http://people.redhat.com/jpound/
Yes Eugene, we are hoping to somehow merge the Platform/Team Bugzilla plug-in with the Mylar one. The lack of support for multiple bug repositories is a major limitation of Mylar's Bugzilla plug-in and the subject of this report. Since our priorities are currently focused on core Mylar features, we hope to solicit someone to contribute this support, or somehow try to marge with Jeff's Platform/Team plug-in efforts. What's even more interesting and valuable about your workspace is that you have multiple bug systems. The Task List already has mos to of the support necessary for handling multiple systems (does local tasks and bugzilla stuff is a contribution). If you're interested in contributing JIRA bug system support could you raise a new report for that and assign it to yourself? I'm happy to support you closely through such an effort and make an necessary changs/patches to org.eclipse.mylar.tasklist. Note that making such a contribution will make you a "Developer" on the project.
Mik, can you please outline interfaces and extension points that has to be implemented by 3rd party bug repository provider? I can't commit tho this task before looking at it. :-) Also, it will be necessary to provide some common api to store repository configuration. BTW Brock Janiczak implemened JIRA Dashboard plugin that probably could be integrated or reused for Mylar. See http://jira-dashboard.tigris.org/
Pretty much all of the task list extension stuff is in the org.eclipse.mylar.bugzilla.ui.tasklist package. Also note the tasklist extension point, which is the first one in ..bugzilla.ui/plugin.xml. The general idea is that you make your own kind of ITask and provide a mechanism for updating it, and externalize any additional information that needs to be stored in the workspace. This stuff is not quite API yet so we will need to improve and move some functionality common to repositories into ..mylar.tasklist. For example, we don't have a generic notion of a query yet, but we should. Take a look and we can discuss further. I suggest making a new report for supporting JIRA that you can leave assigned to me for now. Do you know Brock Janiczak? If so could you introduce me?
This is not directly related, but I wonder if there would be any interest to support forum providers as well? I don't think anyone really uses forums for issue tracking, though, and issues from support forums probably wouldn't make sense in Mylar's context. I am working on a small project that includes a forum client API. The API is currently implemented for vBulletin 3.x and PHPBB2 as Eclipse plugins, but they are nowhere near complete and the API needs a lot of improvement as well. Even if there would be interest in this, I'm not ready to commit to something though, but I might explore the possibility of creating a plugin for Mylar after I've completed the first version of my current project.
The more I think about it, the more it seems that a forum as an issue tracker might not be that bad an idea. Forums are usually more avilable; easier to use and set up than dedicated issue tracking systems. Of course they don't have many of the advanced features that are needed for larger teams, but they could very well be the "cheap mans issue tracker" for small projects. I think I will soon start doing some research on how to best approach this and start some experiments/prototypes.
It would definitely be neat to see a forum provider integrated. My take on it is that whatever you use to communicate and document tasks should be conveniently accessible in the task list so that you can build up a context for that thing. If you guys start experimenting with this send a message please create a bug report where I can walk you through the extension points and API needed to make a provider. Note that the imminent 0.4 release will already have some basic support for this. It allows each task to be associated with a URL, and when you open that task it created an additional editor tab that loads that URL. So you can associate tasks with things like forums and wiki pages. One other neat thing is that anything that you navigate to from page gets automatically captured as a part of your task context. More on this will be in the New & Noteworthy.
Done. See bug 120952 for a discussion on how extensibility should work.
