Removed some code smells

Before committing the current MoveDescriptor implementation I refactored the code a little bit.

There are still some things to do to prepare a new release:

• Test MoveDescriptor with some different situation (missing packages...)
• Take a more detailed look at the patch for project specific settings
• There are some smaller bugfixes needed for a smooth integration of TestNG into the wizard.

Move support finished

Today I finished move support.
There were some smaller enhancements that needed to be done.
But now everthing seems to work fine.
I think this will be the feature-freeze for the next upcoming moreUnit-Release.

Misery of move - SOLVED

Today I solved the problem of missing imports and package declaration.
The following method call is the reason

MoveDescriptor#setMember

This method instantiates the wrong MoveProcessor (or in more detail the wrong Policy).
Using

MoveDescriptor#setResources

is the solution :-)

Misery of move

Today I recognized that the move refactoring doesn't work correctly. Imports and package declarations are missing :-(
I'm wondering how long this will take to solve.
Why aren't there any examples and no documentation :-(

Magic of move

Today is move refactoring day ;-)
After a long time, today I have implemented move refactoring via descriptors.
The NPE I had on Friday was a bug which is fixed in 3.4 M 3.
The last thing I have to do now is to get the correct source folder for the refactoring.

It's working!!!!

After lots of disappointing hours I have made a great progress tonight.
Rename refactorings work now with descriptors.
The problem was the following line:
renameJavaElementDescriptor.setJavaElement(typeToRename.getCompilationUnit());

If I don't get the compilation unit of the type the refactoring processor does not get initialized and the checkFinalConditions crashed with a NPE.

After this I tried to implement the move refactoring.
The move seems not to work fine yet:

java.lang.NullPointerException
at org.eclipse.jdt.internal.corext.refactoring.reorg.DeleteChangeCreator.createDeleteChange(DeleteChangeCreator.java:83)
at org.eclipse.jdt.internal.corext.refactoring.reorg.ReorgPolicyFactory$MoveSubCuElementsPolicy.createChange(ReorgPolicyFactory.java:1812)
at org.eclipse.jdt.internal.corext.refactoring.reorg.JavaMoveProcessor.createChange(JavaMoveProcessor.java:158)
at org.eclipse.ltk.core.refactoring.participants.ProcessorBasedRefactoring.createChange(ProcessorBasedRefactoring.java:234)
at org.moreunit.refactoring.MoveClassParticipant.createChange(MoveClassParticipant.java:115)
at org.eclipse.ltk.core.refactoring.participants.ProcessorBasedRefactoring.createChange(ProcessorBasedRefactoring.java:250)
at org.eclipse.ltk.core.refactoring.CreateChangeOperation.run(CreateChangeOperation.java:121)
at org.eclipse.ltk.core.refactoring.PerformChangeOperation.run(PerformChangeOperation.java:209)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1797)
at org.eclipse.ltk.internal.ui.refactoring.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:87)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:113)

But some more time for coding and this will be solved hopefully.

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.

Integration of TestmethodCreator

The integration of TestmethodCreator is finished.
The preference page is split up in two pages as well.
Now the TestNG support can be implemented which should be quite easy now.

Tests written

I've written some tests for TestMethodCreator and found a small bug in my implementation.

TestMethodCreator implemented

The implementation of TestMethodCreator is almost finished. Some more tests are needed and then I can integrate it into the plugin.

Implementation of TestmethodCreator

Today I worked on the implementation of TestmethodCreator (TestNG)-support, but I'm not quite sure about the design of this class (encapsulation of preferences like JUnit3/4 as well?).

Started TestNG support

Yesterday I started the TestNG support.
I decided to implement a creator-class which encapsulates the creation of testmethods.
As there are several different types of test (JUnit 3.8, JUnit 4, TestNG, additional tests for exisiting testmethods), I think this is a good idea.

Fixed broken tests

After switching back to JUnit 3.8 I realized that the tests were broken.
There was a bug in SelectedJavaProjectProvider which broke the tests.
But now everything works fine again :)

Switching back to JUnit 3.8

I was not able to figure out what the reason is.
If I switch back to JUnit 3.8 everything works fine.
So this seems to be my choice because after searching for a while it seems that there are many other people having the same problem (without solution).

No runnable methods

For yesterdays bug I wanted to write a test, but I recognized that the plugin tests don't run anymore: Exception, no runnable methods.
At the moment I can not see the reason for this problem.
Googling for this message said that missing annotations cause this exception, but adding the required annotation didn't help :(

Bug when switching back

Today I got some feedback that switching back from the test is not working.
If you have two classes Example.java and ExamplePlusExtension.java and a test ExamplePlusExtensionTest.java and although flexible test case naming is not activated moreUnit switches to Example.java.
There are two reasons for this bad behaviour:
1. TestCaseTypeFacade#getCorrespondingClassUnderTest doesn't use the pref and uses flexible testcase naming pre default
2. If MoreUnit finds more than one possible class under test it just switches to the first one and doesn't ask the user to make a choice.

That's bad :(

Shame on me

Thanks to Benny who opened my eyes. Code generation with a protected constructor was the reason for the error. But now I was able to add a detail pref page for TestNG activation.
When Benny wrote the mail with the solution for my stupid mistake I planned not to code after work again. Today I broke my rule, but I have choosen a glas of red vine as my pair programmer and it seems to be a good choice :)

Still no second pref page

I don't what the problem is with this sh** second pref page.
But I made a bugfix (NPE in isJavaFile).
So at least I did something useful tonight :)

Splitting preferences

Today I wanted to start to add support for TestNG.
Therefore I added a new preference page (to get a detail pref page for the additional settings).
It's a pity that I didn't figure out yet why I am getting a "error while creating preference page"-message when opening the preferences all the time :(