Eclipse users are used to download the IDE package that best suite their needs – be it the Scala IDE when writing Scala, Zend Studio when writing PHP, or the JBoss Developer Tools when building (Java) web applications.
As an Eclipse power user you may have recognized already what all of the above products have in common: They are all based on the Eclipse IDE. As such it is dead easy to integrate automated error reporting into any of these IDEs.
This post describes how you can setup automated error reporting for your own IDE-based Eclipse products. It will guide you through both client-side and server side configuration, telling you how to adjust your the Eclipse IDE-based product configuration and how to configure your error reporting server to receive the error reports your customers send.
- Your Eclipse product needs to be based on Eclipse Neon (4.6) or Eclipse Mars (4.5).
- Your product needs to contain the org.eclipse.ui.workbench plug-in.
- Your product needs to run on Java 8 for versions ≥ 2.0, or Java 7 for versions ≤ 1.100.
Note: If your product definition does not contain org.eclipse.ui.workbench, then it’s probably not based on the Eclipse IDE but is rather an Eclipse RCP application or a headless application. In both cases, please check out these blog posts about how to setup automated error reporting for these scenarios.
Eclipse Client-Side Configuration
Step 1: Adjusting the Target Platform
Let’s assume you build your product using Maven and Eclipse Tycho. To pull in the latest version of the automated error reporting client for the Eclipse IDE, add (one of) the following update site to your target platform:
– OR –
From these update sites add the Eclipse Automated Error Reporting and Eclipse EPP Logging Third-Party Dependencies features to your target as show below:
Step 2: Adjusting the Product Definition
After adjusting the target platform, you have to modify your existing product definition. Let’s assume you maintain a .product file which is based on features. Let’s further assume that your product file may look as follows (your product is probably more complex, but for the sake of this example we chose a fairly simple product definition):
Now add the following four features to your product:
- org.eclipse.mylyn.commons, and
The dependency to Mylyn commons notifications is required because the automated error reporting client uses Mylyn notifications to inform users about new errors or status updates. Mylyn commons should be pulled in from the official simultaneous release repository (Neon or Mars). Note that adding Mylyn commons to your product does not pull in the full Mylyn stack – just the notifications.
The automated error reporting client features are contributed by the new update site we added in step 1. We recommend to install the two features listed above from the official error reporting update sites (stable or milestones) because the 3rd-party dependencies feature is not part of the Mars or Neon simultaneous release repositories. Note that all 3rd-party dependencies can be found in the simultaneous repository but there is no single feature that contains them all. So, if you put some manual effort into your product definition, you can just work with simultaneous repository and do not need to add any additional update site.
Step 3: Declaring Your Error Reporting Server Extension
To complete your setup, and to let the Eclipse IDE pick up your error reporting setup automatically, you need to declare an extension of the org.eclipse.epp.logging.aeri.ide.server extension point.
To do so, add the extension to any of your plug-ins. In the simplest configuration, specifying the configuration in the plugin.xml is all you need to do. However, you can customize the IDE-based error reporting in Eclipse in many ways, e.g., by linking to your privacy policies, exchanging how reports are send etc. etc. Please check out this webinar for more details.
Watch the Webinar
That’s all you need to do on the client side. Automated error reporting is now configured to send error reports to your server.
Automated Error Reporting Server Side Configuration
Let’s assume you are working with a fresh and clean version of the free Ctrlflow Automated Error Reporting Service and need to configure it from the ground up. Here is how. If you did not sign up yet, click here…
Sign up now
Step 1: Declare a New Project
Log in into your organization, go to the projects overview page, and click on “New project.” On the next page, enter the common information for your project, i.e., give it a (descriptive) name, a short name, and declare the package namespace this project will be responsible for.
In our example we’ll use “Example Project” as name, “example” as short name, and declare that all error reports that reference classes from org.example or one of its subpackages can be assigned to this project:
Step 2: Configure Server Submission Filters
The Ctrlflow Automated Error Reporting Server allows you to specify filters that decide whether or not an error report (sent by an the Eclipse client) is accepted. We’ll introduce three common filters here. The first filter is the stack trace filter. This filter tests whether a submitted error report mentions at least one relevant class, i.e., a class name that matches at least one project package namespaces (e.g., a class named org.example.some.Class matches the package prefix of your example project defined in step 1).
The second filter is the accepted plug-ins filter. This filter tests whether the error report was issued by a whitelisted plugin. Use this filter if you’d like to receive error reports only for a subset of plug-ins. Enter a bundle id or bundle prefix (followed by a ‘*’) if you want to filter the incoming error reports based on the issuing bundle id. If you don’t want to use that filter, put a wildcard (‘*’) in here:
The third filter is the product id filter. It ensures that the error report occurred on a product you care for. Enter a product id or prefix (followed by a ‘*’) if you want to filter the incoming error reports based on the product id. If you don’t want to use that filter, put a wildcard (‘*’) in here.
That’s it. Your system is ready to receive error reports from your product.
In case you the setup is not working as expected, check out the integrators FAQ.