#1000422
- Created on2011-05-24 07:20
- Reported by
- StatusFixed
- PriorityNormal (3)
- Assigned to
- Milestone
- Plan Level-
- Due Date-
Moving class or renaming package doesn't change source code.
When changing a package, the source code does not get changed accordingly. The refactoring library doesn't support this yet, so it's going to be a larger effort and therefore scheduled for 2.1.
Leave a comment
on 2011-10-10 02:50 *
By Mirco Dotta
Version changed from 2.0.0-beta4 to 2.0.0-beta5-29
Eclipse version changed from Helios to Helios
Component changed from None to Refactoring
(In revision:e514693985992cb57ca2bd9b1dc7137658d6fd41) Initial commit of the Move Class refactoring.
You can either move a single class from a file with multiple definitions
to its own file, or move the complete file. The package declaration will
be updated, and the imports/references to the moved class are adjusted
in the project. The refactoring is also involved when a source file is
moved from the package explorer.
Of course Move Class also works on Traits and Objects.
Some restrictions: it works only on Scala sources, and not across
multiple projects. Also, visibility issues that might arise are completely
ignored.
Fixes #1000422, #1000836, #1000842
Branch: issue/move-class-refactoring-1000422
You can either move a single class from a file with multiple definitions
to its own file, or move the complete file. The package declaration will
be updated, and the imports/references to the moved class are adjusted
in the project. The refactoring is also involved when a source file is
moved from the package explorer.
Of course Move Class also works on Traits and Objects.
Some restrictions: it works only on Scala sources, and not across
multiple projects. Also, visibility issues that might arise are completely
ignored.
Fixes #1000422, #1000836, #1000842
Branch: issue/move-class-refactoring-1000422
on 2012-02-06 09:36 *
By Mirko Stocker
(In revision:be4648920bb3dcaa1d2855e91a4eb8c8e08418be) Initial commit of the Move Class refactoring.
You can either move a single class from a file with multiple definitions to its
own file, or move the complete file. The package declaration will be updated,
and the imports/references to the moved class are adjusted in the project. The
refactoring is also involved when a source file is moved from the package
explorer.
Of course Move Class also works on Traits and Objects.
Some restrictions: it works only on Scala sources, and not across multiple
projects. Also, visibility issues that might arise are completely ignored.
I also implemented Iulian's suggestion to filter the files in the project and to
only create an index for those that contain the name of the class we move or
rename. This speeds up renaming and moving considerably.
Apart from the refactoring changes, I also had to change how existing
compilation units are reconciled: When moving a compilation unit, the
presentation compiler is reset and reconciles all the managed units. At this
point, the moved compilation unit doesn't exist anymore, resulting in an
Exception later on because the resource can't be found anymore. So now we only
reconcile units that exist.
Fixes #1000422, #1000836, #1000842
Branch: issue/move-class-refactoring-1000422
You can either move a single class from a file with multiple definitions to its
own file, or move the complete file. The package declaration will be updated,
and the imports/references to the moved class are adjusted in the project. The
refactoring is also involved when a source file is moved from the package
explorer.
Of course Move Class also works on Traits and Objects.
Some restrictions: it works only on Scala sources, and not across multiple
projects. Also, visibility issues that might arise are completely ignored.
I also implemented Iulian's suggestion to filter the files in the project and to
only create an index for those that contain the name of the class we move or
rename. This speeds up renaming and moving considerably.
Apart from the refactoring changes, I also had to change how existing
compilation units are reconciled: When moving a compilation unit, the
presentation compiler is reset and reconciles all the managed units. At this
point, the moved compilation unit doesn't exist anymore, resulting in an
Exception later on because the resource can't be found anymore. So now we only
reconcile units that exist.
Fixes #1000422, #1000836, #1000842
Branch: issue/move-class-refactoring-1000422
on 2012-02-07 06:20 *
By Mirko Stocker
(In revision:be4648920bb3dcaa1d2855e91a4eb8c8e08418be) Initial commit of the Move Class refactoring.
You can either move a single class from a file with multiple definitions to its
own file, or move the complete file. The package declaration will be updated,
and the imports/references to the moved class are adjusted in the project. The
refactoring is also involved when a source file is moved from the package
explorer.
Of course Move Class also works on Traits and Objects.
Some restrictions: it works only on Scala sources, and not across multiple
projects. Also, visibility issues that might arise are completely ignored.
I also implemented Iulian's suggestion to filter the files in the project and to
only create an index for those that contain the name of the class we move or
rename. This speeds up renaming and moving considerably.
Apart from the refactoring changes, I also had to change how existing
compilation units are reconciled: When moving a compilation unit, the
presentation compiler is reset and reconciles all the managed units. At this
point, the moved compilation unit doesn't exist anymore, resulting in an
Exception later on because the resource can't be found anymore. So now we only
reconcile units that exist.
Fixes #1000422, #1000836, #1000842
Branch: master
You can either move a single class from a file with multiple definitions to its
own file, or move the complete file. The package declaration will be updated,
and the imports/references to the moved class are adjusted in the project. The
refactoring is also involved when a source file is moved from the package
explorer.
Of course Move Class also works on Traits and Objects.
Some restrictions: it works only on Scala sources, and not across multiple
projects. Also, visibility issues that might arise are completely ignored.
I also implemented Iulian's suggestion to filter the files in the project and to
only create an index for those that contain the name of the class we move or
rename. This speeds up renaming and moving considerably.
Apart from the refactoring changes, I also had to change how existing
compilation units are reconciled: When moving a compilation unit, the
presentation compiler is reset and reconciles all the managed units. At this
point, the moved compilation unit doesn't exist anymore, resulting in an
Exception later on because the resource can't be found anymore. So now we only
reconcile units that exist.
Fixes #1000422, #1000836, #1000842
Branch: master
on 2012-03-11 05:44 *
By Mirko Stocker
(In revision:be4648920bb3dcaa1d2855e91a4eb8c8e08418be) Initial commit of the Move Class refactoring.
You can either move a single class from a file with multiple definitions to its
own file, or move the complete file. The package declaration will be updated,
and the imports/references to the moved class are adjusted in the project. The
refactoring is also involved when a source file is moved from the package
explorer.
Of course Move Class also works on Traits and Objects.
Some restrictions: it works only on Scala sources, and not across multiple
projects. Also, visibility issues that might arise are completely ignored.
I also implemented Iulian's suggestion to filter the files in the project and to
only create an index for those that contain the name of the class we move or
rename. This speeds up renaming and moving considerably.
Apart from the refactoring changes, I also had to change how existing
compilation units are reconciled: When moving a compilation unit, the
presentation compiler is reset and reconciles all the managed units. At this
point, the moved compilation unit doesn't exist anymore, resulting in an
Exception later on because the resource can't be found anymore. So now we only
reconcile units that exist.
Fixes #1000422, #1000836, #1000842
Branch: platform/juno
You can either move a single class from a file with multiple definitions to its
own file, or move the complete file. The package declaration will be updated,
and the imports/references to the moved class are adjusted in the project. The
refactoring is also involved when a source file is moved from the package
explorer.
Of course Move Class also works on Traits and Objects.
Some restrictions: it works only on Scala sources, and not across multiple
projects. Also, visibility issues that might arise are completely ignored.
I also implemented Iulian's suggestion to filter the files in the project and to
only create an index for those that contain the name of the class we move or
rename. This speeds up renaming and moving considerably.
Apart from the refactoring changes, I also had to change how existing
compilation units are reconciled: When moving a compilation unit, the
presentation compiler is reset and reconciles all the managed units. At this
point, the moved compilation unit doesn't exist anymore, resulting in an
Exception later on because the resource can't be found anymore. So now we only
reconcile units that exist.
Fixes #1000422, #1000836, #1000842
Branch: platform/juno