Re: [jdt-ui-dev] Refactorings

["Adam Kiezun" <adam.kiezun@xxxxxxx>]

another interesting thing to investigate would be a migrate refactoring
(it's not difficult and useful):

the refactoring takes a map between old package names and new package names
the old ones might not exist in the workspace.
for simplicity we can assume the mapping is a bijection and that old and new
name sets are disjunct.

you write tests covering all cases you can think of
(checking for obscuring (see the language spec) you can leave out -
it's not easy and not critical. we can add it later. to see what it is -
look at RenamePackage refactoring and it's AST analyzer).

ok, you have the tests and all of them fail.
now, start implementing them - one at a time.

below is the outline of the implementation:

you use the SearchEngine to find refs to the old package names (you'll find
the API in SearchEngine class)
you check preconditions (not many and easy)
you rename all packages from the 'old' list (for simplity check that all
'old' package names are unique in the system and the 'new' ones do not
exist)
you update all refs to the 'old' packages

et viola, you're done.
now, the UI: you could reuse the wizard page from RenameParameter
(both columns would have to be made editable, though)

our test infrastructure will be available to you soon.
for now - you can use any automated test method you want (junit preferred)

normally, we do not release any refactoring code that does not have
automated tests for.
some exceptions exit but very few.
a.