The Delete refactoring is available via → or in the context menu when selecting an appropriate element.
A delete refactoring may be applied to the following (physical) elements (i.e. elements that come from the parsing process and are displayed in the Navigation view):
-
Non-external programming elements (e.g. types, methods, fields)
-
Non-external Directories (but not root directories)
-
Non-external Namespaces
-
Dependencies (parser level or aggregated)
When deleting parser level or aggregated dependencies there are up to 3 options:
-
Delete Violating Parser Dependencies (i.e. only delete the violating parser dependencies of a given edge based on parser dependency patterns)
-
Delete Parser Dependencies (i.e. delete the currently contained parser dependencies of a given edge based on parser dependency patterns)
-
Delete parser dependencies Based on End Point (i.e. delete the parser dependencies of a given edge based on end point patterns, after the next 'refresh' there could be more or less matches)
Directories and namespaces, which are recursive structures are currently not deleted recursively. That means, if you delete 'com.hello2morrow.applocation', none of it's child packages are deleted. For this reason empty directories and namespaces are not deletable. In contrast when deleting a type all it's methods and fields or nested types are deleted.
Delete refactorings on (physical) namespaces may also be applied in the (logical) Namespaces view. Since a logical namespace (either in system or module scope) may be based on more than 1 physical namespace, the deletion of a logical namespace might delete several logical namespaces.
Delete refactorings may also be applied in the Architecture view.
Delete refactorings may also be applied in the Exploration, Graph and Dependencies View which are opened based on arbitrary Navigation, Namespace and Architecture view selections.
Delete refactorings can be managed in Refactorings View Section 7.15.2.3, “ Managing Refactorings ”.
