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.