Fixing the move refactoring
Today I did a larger refactoring of my code base, which included many splitting of files with multiple entities and moving stuff to other packages.
I must say that Idea fails miserably in helping me in this task. I'm not sure whether there are situations in which moving an entity or a file to a different package works without manually fixing imports and package declarations. At the very least, moving fails very often.
Maybe I'm doing things the wrong way. As Scala doesn't require the package declaration to match the file location and stuff. If if should be working as intended, I'd like to know how am I supposed to move my stuff around.
There are some open tickets about this. And as this seems like an important feature I am wondering about when this problem will get some attention. Scala's move refactoring is definately more complicated than Java's with multiple entities inside the same file, more complicated import statements and the removal of the need to have package and file location coherent.
To sum it up:
1. Is the move refactoring supposed to be working in general?
2. Am I doing it wrong? How do I move my stuff and have imports changed automatically?
3. Is there any work planned in the move refactoring?
Please sign in to leave a comment.
Move/Copy refactoring is broken. I hope it will be fixed soon.
Best regards,
Alexander Podkhalyuzin.
Four months have passed since the original post, and there are older ones from November 2010 and earlier.
Since moving from Java to Scala five months ago this is the number one pain point for me with IDEA. Some of the key refactorings that were the main reason I really, really loved IDEA for Java are absent for Scala and it really drives me insane. Since I've moved to Scala I now spend about 3-4 hours a week manually moving/renaming/updating stuff that the IDE used to do for me. I understand that (a) the plug-in is new (b) there are lots of things to do and I also appreciate (c) that you guys have already done an awesome job so far - and the plugin is certainly much better than having nothing. :-)
But now that the plugin is somewhat mature I wonder if anyone else shares this view: in terms of improving developer productivity, fixing the 'move' refactoring would really be a - if not THE - top priority. I don't really care about the finer points of syntax highlighting and inspections as long as I have to spend lots of time every time I move a class somewhere to fix broken references.
JetBrains guys: are you working on this? :-)
What is the priority of this related to other things?
PS: For what it's worth, I found a work-around for one little issue: in the Project tree, one cannot currently drag and drop a file from one package to another if it contains only a single Scala class or object - the IDE cancels the move (why?). One can get around this by temporarily generating another class inside the file (type "class X"), then moving the file, then deleting the temporary class. Completely stupid, but it saves a bit of time.
We're going to fix move refactoring in a week or two. Thank you for the reminder :)
Wow, that is excellent news! I look forward to it!
*bump*
So, has it been fixed by now?
If this is not the case, is there a bug we can vote on? I suggets voting on http://youtrack.jetbrains.net/issue/SCL-107 but the fix should include that the described feature also has to be working (I guess that getting the imports right in all files after the refactoring is the hardest part).
It does not appear to be fixed in the latest version, at least not for drag & drop package or object moves.
I second your opinion that this is a very high priority, more important than anything else for me, certainly.
I still waste hours on manually updating references.
Move refactoring is partially fixed now. The work is still in progress...
+1 not working. +1 voting there
Hi, any update to this ?
It's starting to really hurt as the project gets bigger that the basic refacotrings are not working.
Thanks
Since we got no huge support on all tools we moved back from Scala, dropped it from the project. We shall only use it in very specific small situations where refactoring is useless.. aka.. reallllly small projects.
Bad news:(
However I hope Scala plugin for IntelliJ IDEA will be great enough for you as soon as possible, we are doing our best for it.
Best regards,
Alexander Podkhalyuzin.
I must admit I have started to worry about the direction of this plugin.
Seeing updates like play 2 support when the basics don't work doesn't fill me with confidence.
Sorry for previous post, I thought you meant basics in Play 2.0 support.
I can't promise anymore about "move refactoring", which was promised few times before and still not completed, because my promise will look oddly, really sorry for inconveniences.
As for other basic things like "error highlighting" it's becoming better every day, but you know, we are working like experimental physics, because Scala language hasn't complete reference like Java has. So this process is not fast, and tons of issues is really helpful to improve this part of plugin.
Best regards,
Alexander Podkhlayuzin.
I can understand certain things with scala would be difficult.
But renaming a class ???
Moving a class from one package to another ???
I'd be happy with a few very odd issues arising, such as an import with _ not being corrected.
But the basics with static language should be no issue.
It's also the 2nd highest voted issue.
That's now fixed.
Keep in mind that most Move Class refactoring improvements are done in Leda plugin codebase.
The required code changes depend on correspondingly patched version of Idea so, while there's no new Idea 11 releases or EAPs, we cannot transfer the commits to Nika plugin branch.
All in all, the Move Class refactoring is really, really improved in the recent Leda plugin nightly builds. I recommend to give it a try.
Thanks will take a look.
Tried with leda 122.29 and nightly download of 0.6.77 and it doesn't work.
Am I using the right version ?
0.6.77 is a release version of the plugin, please use 0.6.96+ nightly build from here:
http://confluence.jetbrains.net/display/SCA/Scala+Plugin+Nightly+Builds+for+Leda
Thanks, that works.
Was using http://www.jetbrains.com/idea/plugins/scala-nightly-leda.xml as repo.
Should this be working ?
Thanks
That was the "daily nightly build" so the auto-updating haven't noticed it yet :)
I just want to make sure no one thinks this is working.
I did an (actually not that large) move refactoring two weeks ago. Needless to say I had to fix the usual bunch of errors in many files (all the moved files and those depending on them). Besides this, Intellij decided to reformat some of the moved files, introducing linebreaks and other whitespace into my XML-code (which is using the builtin XML literals). So after getting the code to compile again by adjusting all the package and import statements, my XML-parser/writer was riddled with bugs.
Also the handling of companion objects doesn't work at all.
Also I'm observing that imports handling is not working well at all. When using the scala-specific features (renaming, excluding, chaining), Intellij doesn't get it. It thinks imported things aren't there; import by intention doesn't fix it (and you can call the intention over and over again).
My uneducated guess is that you have to fix your import-handling before you can fix the moving.
Unfortunately I don't think it is working too, but I'm tired to ask Pavel to make it working (because move/copy is his subsystem, and I don't want to say "Fixing the move refactoring", actually this refactoring needs to be rewritten from zero point for Scala code only and not to use move refactoring, which was designed for Java code). I'll do it myself or ask Ksenia to do it before IDEA 12 release (to make it completely implemented or at some stable point, which is not harmful), I'm really sorry for all incoveniences from this non-working refactoring, it's our shame.
Best regards,
Alexander Podkhalyuzin.
Would it be a good idea to disable this refactoring for Scala until a good implementation is available?
I imagine questions like 'when will there be a Move refactoring soon?' are less embarassing to answer then 'why did your Move refactor mess up my code?'
There was an initial misconception regarding the issues with the Move Refactoring.
Previously, there was no refactoring implementation at all, so IDEA applied (by an oversight) a built-in Java refactoring to Scala classes. Thus all the "bugs" were expected. The refactoring was not something to be fxed, but rather something to be made.
Currently, the move refactoring is "fixed" in the sense that there is now an actual implementation available. Yet it's not completely "fixed" from the standpoint of remaining bugs (most of which are due to problems outside of the move refactoring per se).
> Also I'm observing that imports handling is not working well at all. When using the scala-specific features (renaming, excluding, chaining), Intellij doesn't get it. It thinks imported things aren't there; import by intention doesn't fix it (and you can call the intention over and over again).
> My uneducated guess is that you have to fix your import-handling before you can fix the moving.
That's a wise guess. Import handling bugs are the primary cause of many misbehaviors revealed in the process of move refactoring. We really need to fix the import handling for the move refactoring to work properly.
> Besides this, Intellij decided to reformat some of the moved files, introducing linebreaks and other whitespace into my XML-code.
Are you using the Leda version of the plugin? The problem with reformatting should be already fixed.
P.S. We have transferred the move refactoring commits to the Nika branch only yesterday, after the new Idea 11 EAP (because of the dependencies on corresponding Idea patches).
In 2017, move refactor is still awful. And in python code base. Imports fail miserably to be refactored all around the code base. Not even in the moved files themselves neither in the files that use those files. Awful workflow.