Bug 101524 - Support for extension refactoring for extension point ids
Summary: Support for extension refactoring for extension point ids
Status: RESOLVED FIXED
Alias: None
Product: PDE
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows XP
: P3 enhancement (vote)
Target Milestone: 3.4 M3   Edit
Assignee: Brian Bauman CLA
QA Contact:
URL:
Whiteboard:
Keywords: bugday, noteworthy
: 108350 186184 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-06-23 14:44 EDT by Michael Valenta CLA
Modified: 2007-10-27 03:50 EDT (History)
6 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Valenta CLA 2005-06-23 14:44:06 EDT 
I was dividing a test plugin I have into separate plugins. I used the Java 
Move refactoring to move a bucnh of classes. It would be nice if a similar 
option existed for moving the extensions defined in the plugin manifest. Here 
are a couple of possibilities to think about:

1) PDE registeres a Java Move participant that will move any extensions that 
reference any of the classes being moved. This is the deluxe solution.

2) The plugin manifest editor provides a Move command that can move one or 
more selected extensions to another plugin.

In both cases, you would want to be able to move a subset of the children of 
any given extension definition.
Comment 1 Wassim Melhem CLA 2007-04-15 01:05:51 EDT 
*** Bug 108350 has been marked as a duplicate of this bug. ***
Comment 2 Wassim Melhem CLA 2007-05-09 12:55:06 EDT 
*** Bug 186184 has been marked as a duplicate of this bug. ***
Comment 3 Chris Aniszczyk CLA 2007-09-27 11:51:13 EDT 
Let's look at this in M3
Comment 4 Chris Aniszczyk CLA 2007-10-02 16:07:31 EDT 
Curtis, if you're bored with Help context id hell, this one could serve as some entertainment.
Comment 5 Brian Bauman CLA 2007-10-02 16:31:32 EDT 
This could range from simple to more complex.  If we refactor the extension point id, we could find and update the corresponding old ids.  This should be pretty straight forward.  

We could go a step further and if the user refactors an attribute or element, we could try to update each plug-in referencing the changed elements.  I have not had a chance to play around with it, but I think this would be a bit more challenging than the first.
Comment 6 Chris Aniszczyk CLA 2007-10-02 16:34:35 EDT 
I updated the title to focus only one the first scenario.

The second scenario could be tracked in another bug.
Comment 7 Brian Bauman CLA 2007-10-26 19:25:22 EDT 
Done :)

During the testing I turned up another scenario we might want to handle (bug 207643).  I also noticed schema definitions have references to the plug-in id and point of which they describe.  Opened bug 207646 to track refactoring those values as well.

This patch does not fix bug 123260.  The only references updated are those in the plugin.xml's.  

While I was in there, I fixed up some deprecated code and added a nmumonic for the Bundle-SymbolicName refactoring code.

One step closer to refactoring perfection ;-)
Comment 8 Wassim Melhem CLA 2007-10-27 03:50:42 EDT 
Nice work, Brian.

btw, don't worry, I am not up that late.  I'm in Romania.  It's morning :)