#1000842
- Created on2012-01-07 15:14
- Reported by
- StatusFixed
- PriorityNormal (3)
- Assigned to
- Milestone-
- Plan Level-
- Due Date-
After creation of new package and moving there Scala stuff *.class'es still generate in old target
Cleaning/Manual deletion don't help.
0. Be sure that you're working under Scala perspective
1. Create package with some name (ex. 'pkg')
2. Create Scala class in package created in previous step (ex. 'SCls')
3. Create package inside of package created on step 1 (ex. 'pkg.subpkg')
4. Move class with mouse into package created on step 3 or with Menu action 'Refactor"->"Move"
5. Observe, that under file system .class files are NOT under package, where they were moved on step 4 ('pkg.subpkg'). They still are under package where they were created ('pkg').
6. Make menu action "Project"->"Clean..." [->"Build Project"]. Observe that it didn't help.
7.. Manually delete target/classes directory and perform actions described in step 6. Observe, that it didn't help.
0. Be sure that you're working under Scala perspective
1. Create package with some name (ex. 'pkg')
2. Create Scala class in package created in previous step (ex. 'SCls')
3. Create package inside of package created on step 1 (ex. 'pkg.subpkg')
4. Move class with mouse into package created on step 3 or with Menu action 'Refactor"->"Move"
5. Observe, that under file system .class files are NOT under package, where they were moved on step 4 ('pkg.subpkg'). They still are under package where they were created ('pkg').
6. Make menu action "Project"->"Clean..." [->"Build Project"]. Observe that it didn't help.
7.. Manually delete target/classes directory and perform actions described in step 6. Observe, that it didn't help.
Leave a comment
on 2012-01-07 20:14 *
By dionis.argiri
Seems that root cause of this problem is that package name is not updated when moving class.
So changing package inside of the file from "package name.dargiri.pkg" to "package name.dargiri.pkg.subpkg" should solve the problem.
So changing package inside of the file from "package name.dargiri.pkg" to "package name.dargiri.pkg.subpkg" should solve the problem.
You're correct, I'm currently working on a Move refactoring which will fix this.
(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 15: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 12: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 10: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