Alex headshot

AlBlue’s Blog

Macs, Modularity and More

I'm back and bugging

2007, eclipse

It's been a while since I posted anything Eclipse-related on my personal blog, since a lot of the Eclipse-related energy goes into EclipseZone. But since Europa with Mylyn came out, I've become addicted to bugs. So much so, I've gone through my list of bugs closing and housekeeping a few things (including an open bug I raised against Eclipse 2.1M3 that was fixed a long time ago). I've also been filing a few new bugs, and in a couple of places, providing the odd patch too.

It's never been easier to file or view bugs at Eclipse.org. When you install Mylyn, it comes with the repository definition for Eclipse.org built-in; it even lets you sign up for new accounts if you don't have one. A non-obvious fact is that you can create queries to look for existing bug reports; in the 'repositories view' if you right-click you can come up with a list to query bugs. I'd have preferred to see this as a menu option; I'm not a big fan of 'new' items not being in the 'new' menu. (Sidenote to Eclipse developers generally; view actions are great for processing items that are already in the view, like filtering, expanding/zooming etc. However, they're not great for changing state; people won't expect to look there to do things. If you've got a New item, then put it in the New menu.)

I even managed to figure out what was up with Planet Eclipse's titles. And as Gunnar suspected, it was an issue with Safari; for some reason, it just barfs at <title> elements, not even being accessible by the DOM. A quick rename of that later, and the titles show up in Safari. Having the bug staring at me in the face (especially when I said I'd take a look at it, and then forgot) was a good way of making it happen.

Update: it's now been fixed in the Screenshot of Planet Eclipse titles on SafariHooray! The Planet Eclipse Safari bug has been fixed! Way to go, Gunnar.

We had a few comments on EclipseZone a while ago about making it easier to fix Eclispe. Mylyn is certainly a good start towards that. However, there's two other things that can be improved to make it easier to fix Eclipse:

Make it much easier to submit patches.

Yes, it's easy to submit patches when you've got the plug-in checked out into your workspace; that's not the issue. Assuming you know which plug-in to look for, actually getting it is a pain. Despite there being a 1-1 mapping between a plug-in and its location on Eclipse's version control systems, there are many repositories (both Subversion and CVS). What I'd like to be able to do is say 'get me org.eclipse.core.resources' and for Eclipse to figure out where.

Actually, buckminster may turn out to be the answer for this issue. But it really needs to be hidden from the user; I'd like to have a dialog that says "Check out Eclipse component", or be able to go to the plug-ins view and right-click a plugin to say "Check out from CVS".

Speaking of source ... although you can import the source from a plug-in, it doesn't have CVS/SVN information. Why not? It's a large enough bundle anyway; the extra meta-data doesn't have that much overhead in terms of payload. It would also bake-in the known version of the files you were running against instead of having to download HEAD or trying to find simple tags like ECLIPSE_EUROPA. It would seem that distributing the source plug-ins with (anonymous) access would solve all these problems at a stroke; not only do you have the source, but if you code a fix, you can right-click and create a patch straight away. What I do at present is to see if I can find the bug, debug into it, then when I've found it and want to start writing a patch, I have to download the plug-in from the repository (and I've got good at knowing where to look, but it's non obvious for a beginner), find out if the bug has been fixed in HEAD, and if not, step through and try to fix it before submitting a patch. It would be so much easier to miss out that middle step, especially if I've got the source code already.

Provide a search API for looking for known strings or file names.

Actually, the once-you-know-where isn't that difficult. Sometimes, it's just solving the where-is-it problem. This is even an issue for seasoned developers; each iteration refactors code to live in different places. So whilst you may think org.eclipse.core.runtime.IProgressMonitor should live in the org.eclipse.core.runtime plug-in, that was only true once. (Those looking for it should note it was mentioned in the New and Noteworthy for 3.2, and now lives in org.eclipse.equinox.common, along with others like IStatus, Status and MultiStatus.)

It is possible to add the source to the Java Search Path, but what that does is to link the source that exists into the workspace (NB only classes; resources or properties files aren't included). Your choices are to either import everything (which takes extra time to do searches) or just import a cross-section of plug-ins, hoping it's in one of them. This kind of search could easily be done by checking out HEAD of each of the repositories, and building up an index of file-name to repository-location mapping. It would be a drain to do over a slow or remote connection, but having a tool that could run nearer to the Eclipse repositories would be great. The next step would be to search for string literals; if you have a dialog with "Hello World RCP" shown, if you could type that into a search engine to see the code that generated it, that would be excellent. (Eclipse throws a few spanners into the works by localising these strings; however, even knowing which plug-in project the string comes from would be a start.)

Some of these things are low-cost, and could be done relatively easily. For example, the mapping of plug-in name to CVS location is probably already well known; and it doesn't change that often (though it does occasionally). Knowing what version of a plug-in that came with (say) Europa is a bit more tricky; but even that's do-able. One example would be to merge in the CVS files into the bundle; the other would be to add the CVS repository information/date into the bundle's manifest for extraction by other utilities. Either of these would be enough to solve that problem.

Anyway, after a fair hiatus of not doing much in the bug reporting or bug fixing world, I'm now back and bugging.