How to contribute to Eclipse projects…

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!

This entry was posted in Eclipse. Bookmark the permalink.

11 Responses to How to contribute to Eclipse projects…

  1. Tomasz Zarna says:

    Sometimes it’s much faster to find the code snippet by using PDE’s Plug-in Spy (http://www.eclipse.org/pde/incubator/spy/). At least this is what I’ve started using recently for any UI stuff. For inner guts, breakpoints are still the best way I know too.

    Cheers

    PS. Cool post Remy, I hope you don’t mind if I use it to answer “how to contribute” questions.

  2. Remy says:

    Tomasz, your comment about the Plug-in Spy is very true. I have not used it very much because I never remember its existence but it has helped me a lot on the few times that I did invoke that keybinding. :)

    Also, please feel free to link prospective contributors to this post!

  3. Thanks for you help with triage Remy!

  4. Ian Bull says:

    Remy,

    This is an excellent post! I have been hacking / working / contributing / committing to eclipse for 4 years and I found this very useful. Maybe we should look at turning something like this into a wiki pag at Eclipse.

  5. Remy says:

    Darin: You’re welcome, happy to help!

    Ian: I think that’s a great idea. I know some projects like Platform/UI and Mylyn already have some kind of guide for prospective contributors on the wiki but it’d be nice if we could add more to it.

  6. Wayne Beaton says:

    Hi Remy. Please consider submitting this as an article for Eclipse Corner.

  7. Remy says:

    Wayne, I’ve filed bug 222105.

  8. Mik Kersten says:

    Remy: note that if you’re using Mylyn, you can save quite a few clicks by creating a patch into the clipboard, and then using the task editor to attach the contents of the clipboard.

    It would be even easier if we had the following feature. I marked it for bugday in case anyone is interested.

    152213: support creating patches by dragging change set onto task editor
    https://bugs.eclipse.org/bugs/show_bug.cgi?id=152213

  9. Remy says:

    Thanks for the tip, Mik. I don’t use Mylyn myself but I’m sure other people will find this useful.

  10. Werner Keil says:

    Well there are lots of ways to contribute to Eclipse. Not just the CIA or other agencies require the help of skillled translators, another 3-digit “agency” from the East Coast also highly appreciates your support.

    Eclipse Babel, lead by IBM, but with various contributors including Aptana, Adobe or Borland deals with all forms of Eclipse Globalization and i18n. Not limited to application content, but more and more also other aspects like web, XML or podcasts come across the Babel “radar”.

    See http://www.eclipse.org/babel/

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

*