While working on non-IDE products, one problem often approach us: If something goes wrong when a user is using the product, how do we actually get them to report the problems back to us? Searching for error logs on the harddrive and send them to support@? Actually a pretty brittle approach. From an Eclipse perspective, it’s pretty clear what to do: fire up the webbrowser, go to bugs.eclipse.org and enter a new bug report. But wait…isn’t that even more complicated? Depending on your audience, 186 bugzilla products with 2564 components offers a pretty good chance to file the bug against the wrong project.

If your user is unable to choose the right component, you actually did a pretty good job of seamlessly integrating your plugin into Eclipse 😉 Some time ago, Mylyn introduced a little feature to actually help users with this problem. Whenever they see an exception in the Error Log, you just right-click it and select “Report as Bug”. Depending on the stacktrace of the problem, it can automatically map the exception to the right product and component in Eclipse.

As Mylyn provides this as a generic mechanism every project can hook into, this is an easy way to help your users and contributors to provide feedback. All you need to do is to provide the right set of mappings from your package namespace to the corresponding Bugzilla attributes.

<extension point="org.eclipse.mylyn.tasks.bugs.support">
  <product
      featureId="org.eclipse.egit" id="org.eclipse.egit" providerId="org.eclipse"/>

    <mapping namespace="org.eclipse.egit.ui" productId="org.eclipse.egit">
      <property name="product" value="EGit"/>
      <property name="component" value="UI"/>
    </mapping>

    <mapping namespace="org.eclipse.egit.core" productId="org.eclipse.egit">
      <property name="product" value="EGit"/>
      <property name="component" value="Core"/>
    </mapping>

    <mapping namespace="org.eclipse.egit.mylyn" productId="org.eclipse.egit">
      <property name="product" value="EGit"/>
      <property name="component" value="Mylyn"/>
    </mapping>
</extension> 

As you can see in the example, we define two types of mapping. The first one is the product mapping. This essentially tells Mylyn to which task repository your project belongs. As we’re using EGit in this example, we’re using the task repository definition of the Eclipse.org Bugzilla instance (see below how to create your own repository provider definition). Once we have this definition in place, the mappings define the exact products and components the bugs should be filed against. If you look at the highlighted mapping above, we’re mapping all exceptions that occurred in the “org.eclipse.egit.core” java package namespace automatically to the EGit product and set the component to Core when the user is about to create a new task. Once you’ve done this, users will automatically get the right choice of options when opening a new Bugzilla bug.

So you’re not an Eclipse.org project? No problem! The same works with other task repositoryes as well which is highly interesting for products based on Eclipse or if your plugin is using a bug tracker outside the Eclipse.org infrastructure (eg. GitHub).

You can always define a new provider and point to the task repository you need and the connector to use. Below you see the extension for Eclipse.org which is contributed by Mylyn.

<provider categoryId="org.eclipse.mylyn.tasks.bugs.openSource"
                        description="Eclipse open source community bug tracker"
                        icon="icons/branding32/eclipse.png"
                        id="org.eclipse" name="Eclipse.org"
                        url="http://eclipse.org/" />
                <mapping namespace="org.eclipse">
                        <repository kind="bugzilla"
                          url="https://bugs.eclipse.org/bugs">
                        </repository>
                </mapping>
</provider>

With this at hand, I’d love to hear how you encourage your community to contribute back in form of bug reports and feature enhancements?¹