Action to compare a callin method with its base method

[stephan]

I would like to provide a menu action for comparing a callin method with the base method it replaces. This would specifically serve those cases, where a large base method is initially copied into the role (using inferred callouts for accessing base members). When the base method evolves this compare action should support to keep the role method in sync with its base.

[stephan]

r22646 gives an initial implementation:

• Add a command to the context menu's submenu "Compare With", command is called ("Compare With>") "Bound base method"
  • Providing the command as a menu contribution requires to forward declare the containing submenu (including the label "Compare With").
• If selection is a callin method, find a corresponding callin binding and extract the bound base method from there
• If selection is a callin binding directly use role and base method
• Kick off a JavaCompareAction to show a dialog comparing both methods.

Unfortunately, JavaCompareAction does not allow to edit its content. It seems a CompareEditor would be needed rather than a CompareDialog. However, CompareAction which uses a CompareEditor can not handle IJavaElements.

So, ideally we would need a mixture of both actions.

[stephan]

The feature has been partially re-written in r22704 as to support editing in the compare editor.

This implementation still has a few quirks and rough edges:

• the LHS starts with displaying the whole compilation unit and only after a first save it focusses on the actual role method.
• after editing the source range is not adjusted
• when the RHS is from source, too, it has a similar issue with focussing.
• strings still need to be externalized

Apart from these, the feature starts to be usable just as intended.

[stephan]

Replying to stephan:

* the LHS starts with displaying the whole compilation unit and only after a first save it focusses on the actual role method.

This is Eclipse bug 291695. An advance patch-team has been committed in r22713.

* after editing the source range is not adjusted

Seems to be another Eclipse bug, not yet reported.

* when the RHS is from source, too, it has a similar issue with focussing.

Still observed.

* strings still need to be externalized

Done in r22712.

Thus at this point only bullet three should be fixed on our side. Investigating.

[stephan]

Replying to stephan:

Replying to stephan:

* when the RHS is from source, too, it has a similar issue with focussing.

Still observed.

Fixed in r22717, thus this feature works to satisfaction.