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

Bug 166731

Summary: [refactoring scripts] Refactoring script can't be applied to dependent projects
Product: [Eclipse Project] JDT Reporter: Eugene Kuleshov <ekuleshov>
Component: UIAssignee: JDT-UI-Inbox <jdt-ui-inbox>
Status: CLOSED WONTFIX QA Contact:
Severity: normal    
Priority: P3    
Version: 3.3   
Target Milestone: ---   
Hardware: PC   
OS: All   
Whiteboard: stalebug

Description Eugene Kuleshov CLA 2006-12-04 21:50:04 EST 
I've tried to use refactoring scripts to update dependent projects to new API, but apparently
it does not work like thought.

Mylar team has been carefully committing refactoring
history to CVS. I thought that I can checkout Mylar from CVS, generate refactoring script
for the period since my last integration and then apply that script on my own projects
that have dependencies on Mylar. So far, so good. I got the project, refactoring history
and even generated script. But when I was trying to apply this script it failed, complaining
that class moved by refactoring is not there. Since refactoring already been applied to
Mylar this class is already in its new location.

So, I think that wizard for applying
refactoring scripts should allow to ignore/skip these warnings if files participated in
refactoring are not found, but after that should search refactoring participants in this
new workspace (those participants that didn't exist when refactoring was created in first
place, e.g. new projects, classes, etc).

It would also make sense to allow to choose
what projects should participate when refactoring script is applied. So, user can speed
things up and could avoid scanning the whole workspace.
Comment 1 Martin Aeschlimann CLA 2006-12-11 11:43:22 EST 
To use refactoring scripts, you need Mylar in the original source version, with your code, everything compiling fine and then perform the scripts so we can guarantee that the refacturing does 100% accurate changes. That only works if Mylar is in source.

If you have Mylar in binary and they use the refactoring history, you don't need to use refactoring scripts but can use 'Migrate JAR...' to update the JAR. The action must again be applied on the original JAR and a compiling workspace. Unfortunatly this only works if the JAR in not in a container.

I think it makes sense to migrate a full workspace, saying everybody who references the refactored sources or libs. That's how refactoring always work. As in all refactorings you can exclude changes on the preview page.

I agree that the whole process needs some polishing. We should make sure it also works in the PDE container setup.
Comment 2 Eugene Kuleshov CLA 2006-12-11 13:38:45 EST 
Martin, I know that it will work on the sources, but I think user should be allowed to take a risk and apply scripts without modifying source code for the originating component. Since that code is under version control, user will end up with outgoing changes on that code, and it is better to avoid these kinds of things.

I also think that support for containers is quite critical. Note that PDE is not the only source of classpatch containers and it should be transparent for other container types.

Worth to mention, that my attempts to use migrate jars has failed in the past. After migrating some jar from within workspace I ended up with build path pointing to jar outside of workspace (even if new jar is sitting in the same folder as old one), which is not what I would expected. Though it is a separate issue.
Comment 3 Eclipse Genie CLA 2019-10-02 19:39:30 EDT 
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.