Description Dirk Steinkamp 2022-02-21 14:40:43 EST

Given 
* Project Explorer in hierarchical package presentation
* a package structure like the following

  a +
    + b +
    |   + X.java
    |   + c +
    |       + Y.java
    |
    + d

When
* selecting package "b" 
* invoking the refactoring "Move"
* chosing "d" as destination

Then
all subpackages should be moved, and the resulting package structure should look like this:

  a +
    |
    + d +
        + b +
            + X.java
            + c +
                + Y.java


Instead 
the resulting package structure looks like this:

  a +
    + b +
    |   + c +
    |       + Y.java
    |
    + d +
        + b +
            + X.java

---------------------------------------------

Only the package "a.b" with all classes directly residing in it (here: X) gets moved to "a.d.b". This kind of makes sense when invoking the move-operation from a flat package presentation. But it confuses if used from a hierarchical package presentation.

Use case: we are currently moving a couple of classes/packages away from a project into a separate project for easier reuse. The behavior was quite confusing for us, and at first we didn't have a clue, so we took rescue to some Windows Explorer drag & drop-operation.



I think the move operation for packages should have a checkbox reading something like "also move subpackages", which should be checked by default when invoked from the package explorer with hierarchical package presentation (or maybe be the default anyhow). When this checkbox is checked all subpackages should be processed accordingly.


A workaround so far would be to select all subpackages that contain classes individually in the tree (which seems not intuitive to me), or switch to the flat presentation and select the individual packages there.