The question of how one could contribute to the Eclipse community has been brought up a couple of times on IRC in the past few months. There are a variety of ways of contributing to Eclipse projects, one can help the Eclipse effort by filing bugs and enhancement requests or answering questions on the newsgroup and IRC. The one that comes to mind for most young, aspiring software developers is probably in the form of contributing code, so that’s what I’m going to talk about here.
The easiest way to contribute some of your hand-crafted coded to an Eclipse project is probably by finding a bug that you are interested in fixing or a feature that you are interested in implementing. The Bug Day wiki page is a good start, you can also just run your own Bugzilla queries if you wish. I personally run a query on Bugzilla every couple of hours every day on all Eclipse bugs (the ‘Eclipse’ in this context would be the top-level Eclipse project) to see what’s been filed today to help with the triage work and bug fixing. I’m going to base this “exercise” around a bug that Tomasz filed a couple of days ago, bug 221652.
Not every bug is as straightforward as this one and while I had a feeling that it was a going to be an easy fix, I still wanted to know how the Compare team wanted it done. So, I asked. :) If you find a bug you’re interested in working on but are a little lost, make sure you ask like I did! Someone with the relevant know-how will then be able to give you some pointers and provide more context about the bug like Tomasz did in his reply. Alright, now that we’ve been told how the team wants it fixed, it’s time to start hacking!
Or at least, that’s what code monkeys like me likes to think. But, where do we go from here? How do I know which plug-in the code is in, let alone which class? If you don’t know the answer, you can usually just ask on the bug. But since the Workspace team is a busy bunch, let’s not bother them. Instead, I’m going to walk you through a little trick I use often when I need to find classes at the UI level.
The first thing any plug-in developer should do before writing plug-ins would be to add all of their base target platform’s plug-ins to the Java search scope for easy access via ‘Open Type’. So fire up the ‘Plug-ins’ view and then add them all to the Java search path.
Once you’ve done this, you should also unfilter that secret PDE project from the ‘Package Explorer’ while you’re at it.
You should now see the ‘External Plug-in Libraries’ project in your ‘Package Explorer’, this will come in handy later. Anyway, now that I have all the Java classes at my disposal, I need to start thinking about the bug and where its code comes from. Since I know we’re dealing with wizard pages here, I can make a pretty safe assumption that the wizard page class that the Compare team crafted is going to be subclassing WizardPage. We can use this to our advantage by putting a breakpoint in its constructors and subsequently start up a debugged Eclipse instance. Now if we try to reproduce the bug, the wizard pages will get constructed and our breakpoint should hopefully be hit! :D
Well, look at that, from climbing up the stack trace, we discover that the wizard pages are being constructed within the GenerateDiffFileWizard’s addPages() method. By thinking about the class hierarchy of the user interface elements you are interacting with and placing breakpoints intelligently, you can find classes quite easily. There’s been cases where I’ve setup some breakpoints in places like Button or Label’s setText(String) method with a condition that the passed in string was equal to some value so that the code would stop right when the control was being created. Pretty hacky, but hey, it works. ;) Desperate times calls for desperate measures, as I often like to say.
In any case, now that you’ve identified the class(es) you’re interested in (GenerateDiffFileWizard and its inner class OptionsPage, in my case), you should use the ‘Link With Editor’ feature.
This will expand the ‘Package Explorer’ and “link” the opened file in the editor with a selection in the ‘Package Explorer’. By scrolling up, I can quickly find the class’s containing jar. This tells me I need to checkout the org.eclipse.team.cvs.ui module from CVS HEAD.
I’ll skip the details about this since I assume all my readers knows how to use the CVS plug-in that comes with the Eclipse SDK. Once that’s taken care of, we should make a new launch configuration and make sure that this launch configuration has the proper plug-ins selected in the ‘Plug-ins’ tab.
You can see that I’ve set my launch configuration to include the copy of org.eclipse.team.cvs.ui from my workspace. Make sure it’s unselected from your ‘Target Platform’ tree. Once that’s taken care of, we should launch Eclipse again to ensure that the bug is still reproducible with the latest code from the repositories. If we get a positive, we can go about and try to fix the bug…
When the bug’s been fixed, a ‘Team > Synchronize’ on the modified projects in question through the context menu is in order so that we can check up on our changes. Once you’ve identified that no conflicts are in place and removed some of the cruft you may or may not have added (such as test code that was commented out or unnecessary/excessive whitespace changes), it’s time to make a patch!
I’d recommend setting the ‘Patch Root’ to ‘Workspace’ even if you’re only patching one project. I caused Paul some grief during my first couple of contributions to Platform/UI since they were all at the ‘Project’ level and made the applying of patches require a few additional mouse clicks on his part. Might as well streamline the whole process for the person that is going to be reviewing your patch, those extra brownie points do add up! Anyway, once the patch has been created, it’s time to attach your patch to bugzilla!
And that’s that! Someone will look at your patch as soon as time permits and provide you with the necessary feedback to improve on it if applicable. Subsequently, with a bit of luck, it could get pushed to the repositories! :D Though, I’m sure none of you need any luck since I’m sure my fellow readers are better programmers than yours truly. ;)
Happy hacking! Don’t be shy about volunteering to help, everybody loves contributions!