MoveDescriptor continued

I tried to get the move refactoring via descriptors to work.
As posted in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=61817
there is bug in the current eclipse release at instantiating the move descriptor.
The workaround posted in this bug doesn't seem to work as well because the createChange implementation tries to instantiate the descriptor the "buggy" way.
As a consequence I have to try to use the latest 3.4 milestone as it is said that this bug is fixed then.

On the search journey

I tried to find some examples or some documentation how to use the new refactoring API via descriptors but wasn't successful. If I try to instantiate a MoveDescriptor from a MoveContribution I get a ClassCastException. In the tests the Descriptors are instantiated directly but this is not recommended.

Still working on move refactoring

Today I figured out, how my workspace code is used, when I startup a eclipse application within eclipse. The problem was a incompatibility with JDT, which I imported in my workspace. After closing all JDT related plugins in my workspace my code is used again. I'm wondering where from the launched eclipse application took the older version of my plugin although it was deactivated in my extension location?
Whatever...
At the moment I'm trying to instantiate a correct MoveDescriptor to handle class move refactorings.

Problem with extension location

Tonight I wanted to progress with move refactorings but I realized a problem with the extension location. If I start a eclipse application from the run dialog the same extension location as the eclipse installtion is used. This is very bad, because I eat my own food and develop MoreUnit with MoreUnit. But now I have a conflict and the manipulated code from my workspace is not used :-(

Started move refactorings

This evening I have taken a look to support move refactorings.
Within Eclipse 3.3 the API has changed and refactorings are done via descriptors.

Worked on TestNG support

Today I extended NewTestCaseWizardPageOne to add TestNG support.
It was necessary to override a several methods to get it work, but I think the majority of the work is done now.

TestCaseWizard

To support TestNG a extended TestCaseWizard is necessary.
As a start I extended the TestCaseWizardPageOne and overrode createJunit4Controls.
The new radio button appears but the finish button doesn't get enabled after clicking.