Package refactoring/renaming and package explorer not synchronized
Start with a simple class definition in a package
Using the package explorer,
The display shows the source file in package2, but the source file has not been changed, i.e., it still has the original package. The source file instead should look like,
This highlights two problems,
This problem is probably related to #1000716
package package1
class Sample { }
Using the package explorer,
- create another package called package2
- drag the source file from package1 to package2.
The display shows the source file in package2, but the source file has not been changed, i.e., it still has the original package. The source file instead should look like,
package package2
class Sample { }
This highlights two problems,
- the file was not changed and
- the file is displayed in the incorrect package.
This problem is probably related to #1000716
Leave a comment
on 2012-01-05 19:48 *
By Mirko Stocker
Assigned to set to Mirko Stocker
Status changed from New to Accepted
I'm currently working on a Move Class refactoring (it's almost done), which will do exactly what you want :-) (plus it will also update all references to the moved class and adapt imports).
(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 21:06 *
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 17:50 *
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 16:14 *
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