OK - Much time has passed, and many things have happened I need to catch up on. Have asked some questions on the bug mail and gotten good guidance from Markus. Also, my proposal for giving a talk at EclipseCon about doing contributions like this has been accepted. I'll catch up on those things in later entries.

For this one, it's the nuts and bolts of the fix. I have done a lot of surfing the eclipse code to find what I'm going to change and how. I downloaded a new integ of eclipse to work with, and got the source straight out of the PDE to do the source surfing. Grabbed a bunch of packages just to make sure I had it covered.

To avoid more of my bad experiences on my last contribution, I want to keep track of which packages I need and which files I intend to change, and get no more than that once I start messing with CVS. Note you can work with the PDE to get source to mess with, but the test packages are missing, and you need to get them directly from CVS if you're going to alter tests. So, you might as well get everything from CVS so you can keep it coordinated.

I won't go through the boring details of all the surfing and tracing I did to find the spots in the code I will need to change. Suffice it to say you have to do a lot of this when making eclipse changes. It is (as we say in Colorado) a big honkin' bunch of code, and it is factored into thousands of tiny specialized method calls. The "Search" menu and pop-up menu "Open Declaration" commands are your best friends.

For UI classes, do a text file search for text on the display. That may lead you straight to a utility class with the text as a comment, or to a preferences file with the text. From there, you can search for the preferences file constant ID or for a class that references the utility class.

For internal classes, you need to do more digging. Since assertions will be enabled through a VM arg, I searched for "vm arg" in a file text search, and got a haystack full of hits. I knew this would also have something to do with a launch configuration, so that narrowed it down quite a bit.

Once you've got a good suspect target class, set a breakpoint in the spot you think is the most likely, and fire up eclipse in a debugger to step through the code and watch it do its thing. That's the way I narrowed down what classes were involved in the changes I'll have to make. Here's the list I eventually got to:

Packages/files needed:
org.eclipse.jdt.junit
JUnitTabGroup
JUnitLaunchShortcut
JUnitPreferencePage

org.eclipse.pde.ui
AbstractPDELaunchConfigurationTabGroup
JUnitWorkbenchShortcut

(For testing)
org.eclipse.jdt.ui.tests
org.eclipse.test.performance