Community
Participate
Working Groups
We are developing a large Eclipse-based product and our plug-ins' source code is architected through layers. Plug-ins in layer N are built against plug-ins of layer N-1 which are in the target environment as opposed to sit in the workspace. Lower layers publish baselines on a regular basis that are subsequently adopted by upper layers. The refactoring feature is very useful when the only affected plug-ins belong to the same layer. But becomes useless when the scope crosses the layer boundary since we never can have a single baseline with all plug-ins' source code together in the same workspace. It would be extremely convenient to be able to serialize refactoring operations so they could be later "replayed" during the adoption of a refactored layer.
Move to JDT/UI
We have looked into this for 3.1 but an investigation has shown that this isn't easy to achive. There are three big issues to be solved for distributed refactorings (for which we don't have a good solution yet): - most refactorings assume that the code compiles. So if you (re)apply a refactoring you must refactor the original code as well (in our example the N-1 code has to be refactored on the client side as well). Otherwise a second refactoring might fail since the client code doesn't compile anymore This requires that the source exists on client sides. - not all modifications are currently done using refactorings. What can happen is that you do a rename, modify some other parts by hand and execute another rename. If we now apply the first rename on the client side and refactor the WTP code as well we still miss the modification done by hand. As a result the second rename might fail since it depends on such modifications. - when executing the refactoring at the client side, preconditions might fail which didn't when applying the refactoring on the library only. This can lead to refactorings which aren't semantic preserving. However the solution here is easy. Just warn the user and apply the changes. Given that J2SE 5.0 is the focus for 3.1 nothing will happen here.
Note that the expectation here is to *reduce* the amount of work that is required when reacting to changes in other layers, not to eliminate it. In this case, they are already living in a world where their code does not compile because of changes in the lower layer. I believe what is being asked for is just a way to partially automate the process of responding to those changes in the next layer up.
I understand the expectations. But the way refactoring currently works (especially the fact that code containing errors can't be refactored since we don't get an AST with bindings for it) would require a "rewrite" of the refactorings or to improve AST creation in the presence of errors. This is out of the scope for 3.1
Would it make it simpler to implement if the refactoring playback of layer N was made using the pre-refactored version of layer N-1 in the target environment; the result of the refactoring would not compile until the target is manually updated after the refactoring operation?
*** Bug 87871 has been marked as a duplicate of this bug. ***
Could someone comment on the proposal from comment #5. This is a real issue as we are developing larger Eclipse-based applications and cannot afford a central build of all components. Thanks
As outlined in comment #2 this only works if you play back one refactoring. For one refactoring it doesn't make a difference if you reapply the refactoring to layer N-1 or if you update the code afterwards by loading a new library version.
I guess I miss something, if I can reapply in layer N a "rename" or a "move" refactoring operation that occured in a version of layer N-1 that I haven't adopted yet, then it will save me the time of having to manually fix each compile error that would occur after the adoption.
Frederic, the problem comes when you want to replay two refactorings, both happened in layer N-1. I agree that if you only want to replay one refactoring in layer N-1 the approach you described works.
Right, that was my understanding. I personnally believe support for even a single refactoring operation is better than none, but that's subjective.
I will mark this PR as a dup of 106207, which is the official plan item for 3.2 for this feature.
*** This bug has been marked as a duplicate of 106207 ***
