Fingernails getting dirty…

This project has split into two tasks: figure out the design for the changes I’ll have to make, and get the darned jdt tests to run. I’ve made good progress on the first task. I have been working through roadblocks on the second with no results yet.

Designing the Solution
After staring down the code and running a source-level debug a few times, a good solution is starting to come into focus. The issue is that, as tediously belabored in an earlier post, one routine (NewTypeWizardPage.createType) reads in all the “sub-templates” or fragments of different, half-processed information needed to piece together the new class, then passes each piece as parameters to another routine (StubUtility.getCompilationUnitContent) that evaluates the template. In subsequent runs, I found that the addition of the methods is later, back in NewTypeWizardPage.createType, and it is done through the AST (IType) representation of the newly created class.

Considering that Dirk admonished me I have to preserve both the API of the StubUtility.getCompilationUnitContent routine and the original behavior of the whole shebang, I’m left with a fairly clear choice. Either I keep the original routines completely in tact and write a parallel code path to process my new template variables that has a bunch of repeated code from the original (boo hiss – it should be obvious to any decent developer this is a very bad idea.) Or, I refactor the current routines to allow the new functionality of user definable comments and class structure while having it default to the original behavior (yay, woo hoo.)

A couple of things make this interesting. There’s no way I can get away with keeping the API the same (at least not one that I would ever consider…) for StubUtility.getCompilationUnitContent. The reason is that if we are to give the user control of the internal class structure through new template variables, we have to resolve those template variables, and I believe we have to resolve them all in one place. So, we have to pass new data (i.e. the generated method stubs for inherited methods, main method, etc…) into this routine as parameters in addition to its current parameters. So how do I keep the API the same and change it at the same time? That part’s easy, I simply wrap a call to the new API in the old API and default the new variables to safe blanks. Then how do I have it mimic the behavior of the original by default? I can’t claim that part is going to be easy, especially considering I’m changing the mechanism of inserting the generated method stubs and doing it at a different place in the code. I’ll have to experiment to see how to mimic the old behavior.

Trying to Run the jdt Tests
Since this is a blog, it’s tempting to indulge in a huge diatribe about how hard it is to get the jdt junit tests to run. It’s even more tempting to mention complex test infrastructure and setup is a barrier to entry that keeps independent developers from making more contributions to Eclipse, and slows down those of us who try, making us more frustrated and less productive. But far be it from me to give in to such temptation. Just the facts…

The jdt junit test ant scripts fail right away with “cannot locate file” errors, and the junit tests don’t run in isolation. The farthest I got with one of them was a “workspace is locked” error, which implies the junit test got as far as actually executing. That was a fleeting victory, however, and soon had degenerated into “could not find classloader” issues which indicate I screwed up the configuration badly enough that junit tests couldn’t even begin. On top of that the files from the CVS HEAD revision aren’t free of error – there are a lot of compiler defects in a couple of the classes in the “refactoring” directory. This may be unrelated, but it doesn’t give you much confidence in building and running tests successfully.

I’m slowly working through the jdt test ant scripts, fixing paths that point to the wrong directories, and filling in the missing parts of the tree. Though the PDE seems pretty cool at first, it looks like it put the eclipse source in a place outside the tree where the ant scripts don’t expect it, and the directory names are different too. This is probably too screwed up for a single mortal to fix in his spare time. Next step is to erase the whole tree and start over with a blank directory and a fresh CVS sync. I have found in the past that I usually hose things up so badly at first it’s best to start over after some initial exploratory blundering. Most often, I find the blundering is a valuable learning experience and it gives me some knowledge I’ll use later in the project. My suspicion is that I’m mixing Eclipse the running IDE and Eclipse the target tree I’m building and have to keep the two separate.

I have spent some time looking for web resources that explain how to run jdt tests, or any eclipse tests, for that matter. There are a few old complaints floating around of broken tests ala 2003 and 2004, but no instructions. I will write them out as soon as I figure out the magic formula for myself, but at this point, I’m sadly under-qualified.

One silver lining in all this, I finally called up Qwest and complained about my 10kbps download rates that are taking 3 hours to download an Eclipse tree. Needless to say, this is severely stepping on my buzz. They confirmed that with this pricey DSL I’m signed up for, my downloads should be 15 times faster. After trying to blame it on spyware (same speed on two computers, both have anti-spyware software cleaning them regularly), me using a telephone filter on my DSL line (nice try, but NOT), and a bad cable on my end (that seems to throttle the download rates to exactly 10.0 kbps every time but cause no errors? Hmmm…), they agreed to check out their equipment at the central office and run some tests.