Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 101524

Summary:	Support for extension refactoring for extension point ids
Product:	[Eclipse Project] PDE	Reporter:	Michael Valenta <Michael.Valenta>
Component:	UI	Assignee:	Brian Bauman <baumanbr>
Status:	RESOLVED FIXED	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	baumanbr, caniszczyk, Curtis_Windatt, darin.eclipse, hudsonr, wassim.melhem
Version:	3.1	Keywords:	bugday, noteworthy
Target Milestone:	3.4 M3
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description Michael Valenta

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

2007-04-15 01:05:51 EDT

*** Bug 108350 has been marked as a duplicate of this bug. ***

Comment 2 Wassim Melhem

2007-05-09 12:55:06 EDT

*** Bug 186184 has been marked as a duplicate of this bug. ***

Comment 3 Chris Aniszczyk

2007-09-27 11:51:13 EDT

Let's look at this in M3

Comment 4 Chris Aniszczyk

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

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

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

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

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 :)