Community
Participate
Working Groups
An extension point along the following lines would allow for automatic component selection (e.g. for bug 135605): <extension point="org.eclipse.mylar.tasks.repositories"> <bugRepository connector="bugzilla" product="Mylar"/> </extension>
Hmm. Should it have repository url too? I also recall there was an issue opened for linking Eclipse projects to the repositories tht was also suggestin some pluggable relolution mehanisms. E.g. one could use Maven data and search trough stack trace and link package names to product artifacts and extract issue tracking system location from Maven's poms for those artifcats.
Yes, URL should be there too (e.g. helping support generic web Connector). Linking to projects is related (bug 145214).
Balazs: could you make this your next priority? The Welcome stuff is great, but this would be really helpful to have in 2.0 along with the related updates to bug 183606. Please let me know if you would like some pointers about how we use and create extension points. This one would go into ..mylar.tasks.ui/schema/repositories.exsd
*** Bug 152420 has been marked as a duplicate of this bug. ***
An extension point may not be the right way of doing this, because it does not support the producer/consumer separation. For example, an Eclipse-based product may want to handle all bug reports made against Platform in order to ensure response time. For this reason I think that the mapping would best be specified in an external resource (e.g. a plug-in to tracker/product mapping file), and could provide support for things like wildcard matching (e.g. all Errors from package org.eclipse.mylyn.jira.* plug-ins should be logged to repository foo). EPP distros could then specify bugs.eclispe.org, with appropriate product/component mappings, but redistributions would be free to do their own thign. Syntax could be something like: pluginPattern="org.eclispe.mylyn.jira.*" repository="https://bugs.eclipse.org/bugs" attributes="Product=Mylyn;Component=Jira;Version=2.1"
Mik, we really need to support project/product and component/module at the task model. Also, I believe this metadata about component mapping could came from other sources, so it should be possible to plug custom adapter from that information instead/in addition to reading it from proprietary files.
Eugene: it would be nice if we could standardize on project/product and component/module, but we currently support connectors that have no notion of that. For example, an agile project management tool might only use the following attributes: attributes="Kind=Defect;Version=1.0;" We could consider having an optional product= and component= mapping, and having the repository connector specify what that maps to, if appropriate, but this is not for sure an overall win. It would be a win for many Bugzilla and JIRA installs though, and similar bug/issue trackers, so we can consider it.
(In reply to comment #7) > Eugene: it would be nice if we could standardize on project/product and > component/module, but we currently support connectors that have no notion of > that. For example, an agile project management tool might only use the > following attributes: > > attributes="Kind=Defect;Version=1.0;" I don't see how those are useful for mapping to products. Besides, we have 3 or even 4 Mylyn's reference connectors that have notion of project/product and module. > We could consider having an optional product= and component= mapping, and having > the repository connector specify what that maps to, if appropriate, but this is > not for sure an overall win. It would be a win for many Bugzilla and JIRA > installs though, and similar bug/issue trackers, so we can consider it. Exactly. We are missing this component/project mapping not only for this purpose. I can think of a dozen of other places when that would be useful.
Can someone summarize the use case for this enhancement and use of the proposed enhancement? From previous comments it seems like the assumption to have this extension point declared in every plugin, which seem like tough call for all existing platform plugins and I think that some kind of completely external mapping would be more realistic for those plugins. If I am not mistaken, Buckminster guys already did something like that to map projects to version control systems. All in all this issue is probably beyond just Mylyn project and it would make sense to hear what other project leads would think of the proposed solution, so it won't go the same path as Mylyn usage monitor vs. EPP monitor. BTW, for Eclipse projects it might make sense to have some kind of integration with Eclipse portal, though it may require portal to provide mapping from projects/plugin ids to bugzilla components.
Eugene: we can take a bit of time on tomorrow's call for any clarification that you need on this. I have described our solution at the last Architecture Council meeting to a positive response, and when we are ready we will be proceeding with informing the Foundation and/or project leads on how to contribute the necessary mappings.
Created attachment 101187 [details] mylyn/context/zip
I would like to change the current extension point to have a more explicit notion of products and organizations. Instead of using pluginRepository mappings as an entry point I would like to propose the following change: pre. <extension point="org.eclipse.mylyn.tasks.bugs.support"> <category id="org.eclipse.mylyn.tasks.bugs.openSource" name="Open-Source" description="Community supported Open-Source projects"/> <organization id="org.eclipse" name="Eclipse.org" description="Eclipse Open-Source projects" icon="icons/32/eclipse.png"/> <product id="org.eclipse.mylyn" name="Mylyn" description="Task Management and Task-Focused Interface" pluginId="org.eclipse.mylyn" (for branding icon, installed version) /> <productRepositoryMapping namespace="org.eclipse.mylyn" productId="org.eclipse.mylyn" <repository kind="bugzilla" url="https://bugs.eclipse.org/bugs"> </repository> <property name="product" value="Mylyn"> </property> /> <productRepositoryMapping namespace="org.eclipse.mylyn.tasks" productId="org.eclipse.mylyn" <property name="component" value="Tasks"> </property> </product> </extension> The main driver for this is that different vendors may offer support for the same product and hence need different mappings. In the UI the user would be presented with a combo box for selecting the "Organization - Product" when reporting a bug from the error log.
The most commonly used terms in Eclipse that I know of are Provider and Product.
I have extended the extension point to include additional attributes for branding and to allow for ordering categories. Example usage: pre.. <extension point="org.eclipse.mylyn.tasks.bugs.support"> # define category, weight determines ordering <category description="Community supported Open-Source projects" id="org.eclipse.mylyn.tasks.bugs.openSource" name="Open-Source" weight="900" /> <provider categoryId="org.eclipse.mylyn.tasks.bugs.openSource" description="Eclipse Open-Source projects" icon="icons/branding32/eclipse.png" id="org.eclipse" name="Eclipse.org" url="http://eclipse.org/" /> # default mapping for all org.eclipse.* namespaces <mapping namespace="org.eclipse"> <repository kind="bugzilla" url="https://bugs.eclipse.org/bugs"> </repository> </mapping> # Mylyn: only included if org.eclipse.mylyn plug-in is installed <product featureId="org.eclipse.mylyn_feature" id="org.eclipse.mylyn" pluginId="org.eclipse.mylyn" providerId="org.eclipse" url="http://eclipse.org/mylyn/" /> # generic mapping for bug reporting from error log <mapping namespace="org.eclipse.mylyn" productId="org.eclipse.mylyn"> <property name="product" value="Mylyn"> </property> </mapping> # more specific mappings for errors logged by tasks framework <mapping namespace="org.eclipse.mylyn.tasks" productId="org.eclipse.mylyn"> <property name="component" value="Tasks"> </property> </mapping> # PDE: all branding is picked up from org.eclipse.pde feature <product featureId="org.eclipse.pde" id="org.eclipse.pde" providerId="org.eclipse" /> <mapping namespace="org.eclipse.pde" productId="org.eclipse.pde"> <property name="product" value="PDE"> </property> </mapping> </extension>
