Extensible refactorer

[hbchai]

This change accompanies the feature request to make the "pydev_refactoring" extension point overridable:

http://sourceforge.net/tracker/?func=detail&aid=3473592&group_id=85796&atid=577332

The last registered extension for that extension point will be used for the refactoring implementation, and cached by AbstractPyRefactoring .

These changes also make the plugin projects buildable against Eclipse 3.7 .

[fabioz]

Hi Haw-Bin Chai,

Thanks for the patch. I'll try to integrate later this week...

Cheers,

Fabio

On Monday, January 16, 2012, Haw-Bin Chai <
[email protected]>
wrote:

This change accompanies the feature request to make the
"pydev_refactoring" extension point overridable:

http://sourceforge.net/tracker/?func=detail&aid=3473592&group_id=85796&atid=577332

The last registered extension for that extension point will be used for
the refactoring implementation, and cached by AbstractPyRefactoring .

These changes also make the plugin projects buildable against Eclipse 3.7
.

You can merge this Pull Request by running:

git pull https://github.com/hbchai/Pydev extensible_refactorer

Or you can view, comment on it, or merge it online at:

#21

-- Commit Summary --

• Target Eclipse 3.7
• Allow single participant to be overridden.
• Clean up getParticipants().
• Revert from generic method.
• Fix test breakage.

-- File Changes --

M plugins/org.python.pydev.core/.classpath (20)
M
plugins/org.python.pydev.core/src/org/python/pydev/core/ExtensionHelper.java
(57)
M
plugins/org.python.pydev.core/tests/org/python/pydev/core/TestCaseUtils.java
(2)
M
plugins/org.python.pydev.core/tests/org/python/pydev/core/resource_stubs/AbstractIProjectStub.java
(25)
M plugins/org.python.pydev/src/org/python/pydev/builder/PyDevBuilder.java
(1)
M
plugins/org.python.pydev/src/org/python/pydev/editor/actions/PyFormatStd.java
(2)
M
plugins/org.python.pydev/src/org/python/pydev/editor/actions/PyShowOutline.java
(2)
M
plugins/org.python.pydev/src/org/python/pydev/editor/refactoring/AbstractPyRefactoring.java
(2)
M
plugins/org.python.pydev/src/org/python/pydev/ui/pythonpathconf/InterpreterInfo.java
(2)
M
plugins/org.python.pydev/tests_navigator/org/python/pydev/navigator/WorkspaceStub.java
(175)

-- Patch Links --

https://github.com/aptana/Pydev/pull/21.patch
https://github.com/aptana/Pydev/pull/21.diff

---

Reply to this email directly or view it on GitHub:
#21

[hbchai]

Hi Fabio,

Thanks for the patch. I'll try to integrate later this week...

Thanks a lot!

I'd like to ask you about the "org.python" vs. "com.python" projects. Is it important for changes to go in one or the other? And is there (in general) a desire to migrate code from com to org? For example, why do the IPyRefactoring and IPyRefactoring2 interfaces live in different projects?

If this has already been discussed on a forum somewhere, just point me to the thread. :-)

Haw-Bin

[fabioz]

It exists mostly for historical reasons (because there was an open source and a commercial version). There are no real plans to do a migration (although it was done for historical reasons, the separation on the features of each plugin should still be straightforward -- right now I'm setting up a wiki and plan to document some things better there).

Still, if some interface needs to be moved from a com. plugin to an org. plugin, there should be no problem in doing so...

[fabioz]

There's one thing I find strange: the getParticipant() has the allowOverride flag, but it seems it'll get things randomly in that case (the extension registry makes no promises on the order of things)... I think that whenever the allowOverride is true, the returned extension points have would need to implement something as an IParticipantPriority and the one with the lower priority should be returned -- and an error should be raised if more than one is found with the lower priority (still not perfect as if 2 plugin writers want to provide that same one, they probably won't know how to contribute, but at least it'll be reproducible).

[hbchai]

Good point, I was not aware that the order of extensions is non-deterministic.

I think your priority logic suggestion makes sense. It appears that the priority can be represented in an XML tag for each extension declaration, retrieved via getConfigurationElements() for each extension, without modifying the actual extension classes.