- remove getElement from participant interface.
- allow sharing of participants for different element types.
  <renameParticipant
    id="..."
    share="true";
  />
- object state. Implement bean object state interface.
- how to implement special web type rename that renames interface and implementation.
  o provide a special processor that overrides normal Java processor if project
    nature is webnature. This means processor gets scopeState as well.

- package rename. At end we delete an empty folder. Should we sent out a folder delete
  modification. If so participants have to know that the folder doesn't have any children
  upon deletion, but it might have some upon precondition checking. So for resource 
  modifications we have to describe some sort of postcondition. For example: folder
  will be empty on deletion. Can be derived from the ResourceModifications object.
  
- IRefactoringProcessor should not have a method getResourceModification since there
  might be refactorings which don't modifiy resources. For example a database only
  application might want to describe high level database operations as low level
  SQL ops.
  
- what happens if a web plug-in for some reason registers on resource move and on
  package rename. Then it might clash if the package rename also tries to handle
  the move. One argument is that the plug-in knows about its participants and can
  avoid this in code. Another option is that a participant can specify if it is
  interested in the comupted resource modifications. Can be a property for some
  state XML element.

- handling of UNKNOWN paroperty: 
  o throw exception
  o pass to caller
  currently it is turned into true which is the incorrect thing to do. It must be
  false anyway.
  
- ISharedParticipant and propagating data to participant. That doesn't wortk for the
  current implementation. SetNewName and other methods must have an additional object
  parameter. Best is to split this into IShared and INonShared participants.
  
- Source folder and compilation unit processors object state attribute can be simplified
  in the following way:
  <objectState adaptable="org.eclipse.jdt.core.IJavaElement">
      <property name="instanceof" value="IPackageFragmentRoot"/>
  </objectState>
  
- XML expression must support arrays of elements. For example we want to be able
  to move more than one method to a different class. This effects the objectState
  XML element.
  
- more than one processor is available: The preferred processor can't be remembered
  based on the type of the element, since the XML expression can be more complex. So
  the registry must store the preferred user processor based on the list of picked 
  processors. If it is the same has been computed for the element in question than 
  the preferred one can be used. Otherwise the user has to be asked.

- property tester must assumes that projects with no nature have a fake simple nature 
  called "org.eclipse.core.resource.simpleNature". Otherwise the user has to specify the
  empty nature string in XML.

- THE LRU optimazation only works for elements which have a processor. If no processor
  is available we always check all rename processor which can be many. We need some
  other optimazations as well.
  
- determining the participants must be delegated to the processor. Otherwise it is not
  possible to chain processor. Nor is it possible to introduce a JavaModification object
  (similar to ResourceModifications) since the refactoring itself can't be extended.
  
- processors and participants should derive from PlatformObject if the implement IAdaptable

- we should remove the affected project test from the participants and force them to
  specify a language the are working on. The language computer then takes a set of
  projects and computes the effected languages. This will be consistent with what we do
  for processors.
  
- rename processor: how do we handle rename polymorphical for renaming temps. This might
  be a special editor problem. May be we don't allow contributing to temp renames.
  
======================================= UI ===============================================
  
- UI: Label and image of preview viewer. Must be determined by the change element
  structor creator.
  
- NeedsPane flag on previewer ??

- Make pane handling consistent in Error and Preview. In error the pane is for free
  in preview the viewer has to provide the pane.
  
- Composite change in preview tree. Strip away root composite that have only one child.

- Error and Preview page need customizable help id.

- Refactoring Wizard Page: can't provide dialog settings. Too high up in the hierarchy.

- Wizard should be able to disbale preview. To do so processors and participants must
  signal if they want to show a preview. Problem is that we don't know all participants
  upfront. So the processor has to decide this.
  
- RenameRefactoringAction has a hard cast to rename method processor to check for the
  virtual method case.
  
- Currently all refactorings require a save of modiifed resources before the get executed.
  This is necessary due to undo and search infrastructure. We have to find a better solution
  for this since we can't assume that saving resources is the right thing to do.

=================================== Rename ================================================
- rename a Java project must be a participant since a project can have more than 
  one nature. This means we double code from core and there will be different deltas.