Wednesday, September 07, 2005

Something on both the test front and the development front this time...

On the test front, still can't get tests to execute, but had e-mail exchange with Dirk:

Hi John,
the trick is to launch the tests using JUnit Plug-in Test launcher. The launcher makes sure that the Eclipse runtime is setup correctly. The launcher works the same way as the normal JUnit launcher. Simply pick a TestCase or a suite and run it.

Dirk - When I try to run any JUnit test in the jdt test directory as a plug-in test, I get a "no classloader" error.
Could you give me some further advice how to get around this?

- John

For example, I select the file in the Package Explorer, right click, and select Run As... -> JUnit Plug-In Test from the pop-up menu.

I get the following stack trace:

"Error: " java.lang.IllegalArgumentException: No Classloader found for plug-in org.eclipse.jdt.ui.testsjava.lang.IllegalArgumentException: No Classloader found for plug-in org.eclipse.jdt.ui.tests
.runtime.RemotePluginTestRunner.getClassLoader\n( org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.loadSuiteClass( org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.getTest(\n:380)at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests( (Bunch more of stack trace omitted)....

We'll see what he says.

On the development front, I got a new code template for Dirk's proposed new ${type_content} template to appear on the Window->Preferences...->Java->Code Style->Code Templates->Code display.

It took a lot more fiddling than I expected. I had to make changes to a number of files in the org.eclipse.jdt.ui package, and the change kind of mysteriously appeared after not appearing for a while and I'm not sure what was the last change I made to make it work.

There is a file in the templates subdirectory of the package called default-codetemplates.xml. In that file, the text for all the familiar code templates is listed, like $(filecomment) and ${type_declaration) and the like. My first step was to copy and paste ${type_declaration} and edit it to make a new version for the new ${type_content} my first prototype looked something like this:

Eager for results, I fired up Eclipse (select the newly edited package, select Run As...->Eclipse Application, and off it goes - you gotta admit that's pretty slick...) but as foreshadowed, my new code template did not appear in the list.

So, I went searching for references to the "newtype" template (called "New Java files" in the window preferences list, but internally it's "newtype.") I found a bunch of hits, and added what I thought would be the proper corresponding reference to my new template everywhere the "newtype" template was referenced.

The list of files I changes was: - added a new branch to a big stack of if-else's in getText(). - added a static string variable for the template's label. - added a property with the actual text of the template's label. - added several strings for context and ID, and added another branch in a stack of if-else's in the constructor that list the "sub-variables" allowed to appear in the text of my new one. Note I'll likely have to go back and edit this as I make it more real. Also, there's a TODO further down in validateVariables() I'll have to fill in when it's real. The newtype variable requires a package and a type declaration to be valid, and mine will require a type declaration header.
Then there's our old friend default-codetemplates.xml as described above, and that's it.

Huh - only 5 files? It seemed like a lot more when I was doing it. I got most of them on the first try, but my new template still wouldn't appear in the list. After some hair-pulling and tracing of references to defined variables (not just the "newtype" identifier") I think I found the one that was blocking it from appearing. It did seem to unexpectedly appear, so I either lost track of which change I'd made or it needs to be started up twice for some reason for the change to take effect. I couldn't swear to it either way.

...And speaking of unexpected things, remember my pitifully slow DSL connection? After I called and denied any culpability to Qwest, I tried as a lark to swap out the phone chord between the wall and the DSL modem. What would happen but all of a sudden the connection came up to full speed as advertised. 150k-per-second downloads, meaning I can now download a full Eclipse distro in about 8 minutes. Boy, was I wrong about that. It got me thinking that development projects are full of these small assertions we make - many right, but many wrong, and it's always a matter of proving somehow which of your theories are wrong or right until your project starts to work and your tools start acting to your expectations (or your expectations start coming more in line with your tools....)

Next up for this project, I worry about how do I sync/merge with CVS now that I'm making changes and I don't have any CVS privileges? Will Dirk come through and let me know how to run junit tests since I don't want to make any more changes without running regression tests? And will I get to the fun part of making my new template come alive by refactoring some of the code I mentioned in earlier posts?


Post a Comment

<< Home