How to Fix a Bug in Eclipse

Introduction

There are a wide variety of ways that someone can contribute to Eclipse. You can open a bug or enhancement request in Bugzilla, answer some questions on the newsgroup, or just write a blog entry about it on your blog to increase awareness and generate some interest in Eclipse technology amongst your readers. There's also a wiki category of articles related to contributing to the Eclipse community. For those of you that are feeling adventurous, you may wish to venture forth into the Eclipse code base and try to fix a bug or add a feature yourself. If you are one of those individuals, read on.

Find a Bug

The first step to making a code contribution to Eclipse would be to find an itch that you want to scratch. If you don't have one you can think of, you can always run a Bugzilla query and try to look for one. While constructing your query, it would be in your best interests to include the keywords "bugday, helpwanted" to help narrow the search down to simpler bugs if this is your first time making a code contribution to Eclipse. So say you wanted to search for open and simple bugs in the Platform/Team component, your query would look something like the following.

For the purpose of this exercise, bug 221652 will be used as an example of a simple bug that can be easily fixed by a contributor.

Comment on the Bug

Once you have found a bug in Bugzilla that you wish to try your hand at addressing and you've managed to reproduce it locally, you should speak up on the bug by commenting on it. This will let the developers and other people CC'd on the bug know that there is someone interested on working on it and should help prevent duplication of effort. You should also take this opportunity to comment about the solution you are considering pursuing so that the other people can provide input as to whether they feel this is the correct approach or not.

Finding the Source of the Problem

Normally, if you are unsure as to where the problem occurs in the source code, you would ask the developers about it on the bug so that they can provide you with some pointers. If the bug is with the user interface, like it is with bug 221652, then you can try figuring it out yourself by using Plug-in Spy to find the source code based on the results of the introspection operation.

To use Plug-in Spy, you should first bring up the user interface element that the bug occurs in. Now hover your mouse over it and then hit Alt+Shift+F1 (this may be Option+Shift+F1 on a Mac keyboard). Plug-in Spy will analyze the element under your mouse cursor and provide you with a list of information.

Take note of the class name (in this case it is the "active wizard class") and the contributing plug-in. This will tell you the primary class that constructed this element and the plug-in that this class comes from. Now that you know the name of the plug-in, you can search for it in the source code repositories and check it out. Unfortunately, it is usually not very easy for one to find the plug-in projects in question in the source code repositories. As always, if you are stuck, you can always just ask on the bug directly as to which projects you should check out and where they are located. If the particular project provides project set files, or PSFs, you can just download this definition file and import the projects directly from the repository. This is usually the easiest way for an outside contributor to get his or her workspace up and running with a particular project's source code. In the CVS project's case, they have both anonymous and committer PSFs available for download. If such an option is available for you, you should select the "anonymous access" one.

Fixing the Bug

Once you have the source code in your Eclipse workspace, you should startup a second Eclipse instance from your workspace that uses the plug-in you just checked out. You can then verify whether the bug is still reproducible with the latest code in the repository. In your 'Eclipse Application' launch configuration, make sure you have your checked out project selected and the one in your target platform unselected to ensure that PDE picks the right one.

Submitting a Patch

Once you've confirmed that the bug still exists and have fixed it, you should synchronize your project with the repository again by performing 'Team > Synchronize with Repository' through the project's context menu. If there aren't any conflicts then you should go over your changes and make sure any print statements you might have added have been removed and all extraneous whitespace changes have been reverted. Once it's all good to go, you should create a patch for submission into the Bugzilla system.

When creating a patch, make sure you select the option to set the 'Patch Root' to the 'Workspace' if the option is available. This will make it easier for other people to apply your patch to their workspace. Once the patch creation process has completed, you are now ready to submit it into the Bugzilla. Navigate back to the bug report, click on the 'Add an attachment' link and then fill in the relevant information.

When you're done filling in the form, just click the 'Submit' button and your patch will be uploaded to Bugzilla! Don't be discouraged if the developers do not respond to your submission immediately as they may be busy with other things. On the other hand, if the bug stays quiet for an extended period of time, a helpful nudge by commenting on the bug may help remind the developers of your patch once again. Due to the volume of traffic that occurs from Bugzilla emails on any given day, your comment may have slipped off of their radars. Do not despair and keep trying!

Summary

This article has walked you through some simple procedures on how one could find a bug in Bugzilla and subsequently have a fix contributed to the developers. However, as I noted in the introduction, there are many other ways you can contribute to the Eclipse community. You can still help if you don't know how to code through other means such as by filing bugs, answering questions, giving talks, helping with translations, writing documentation or a blog entry about Eclipse.