This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
[200406230100] -there is no way to rename empty package in IDE refactoring doesnt provide its action 'Refactor->Rename' on empty packages (issue 44895) and the 'normal' Rename is disabled(grey) on empty package. I dont see any reason why it shouldn't work. If it's empty then can be simply renamed to anything e.g. package 'a.b.c' can be easily renamed to 'd.e'=> just delete last package part 'c' and create new (if doesn't exist) 'd.e' The greyed=disabled 'Rename' on empty package looks strange.
Huh, that's a mess.
Sounds reasonable to me from UI perspective. It should be possible to rename an empty package.
Appears to be controlled by the refactoring module, not java/project. Main menu item Refactor -> Rename... also explicitly refuses to operate on the default package.
This is not controlled by refactoring module, since in case of empty packages the refactoring module delegates to the default rename action since there is nothing to refactor. AFAIK it is java/project module that disables the rename action (we don't do that).
Actually there are two potential bugs. 1. An empty package cannot be renamed. This is I think the fault of PackageViewChildren. 2. The default package (even if not empty) cannot be renamed as a refactoring operation. This is I think the fault of the refactoring module. Right?
Quoting from related (already closed) issue #44895: "For javac compiler it is not a package ;)" I don't buy this argument. Are we building an IDE for the javac compiler or for human users? Recently pointed out by NetCAT participants. Raising priority and adding '[40cat]' prefix.
> "For javac compiler it is not a package ;)" > I don't buy this argument. Are we building an IDE for the javac compiler or for human users? It was argument, that we cannot do refactoring if this package does not exists. We surely do IDE for human users. Maybe you missed my previous comment: "I don't say that this is not a bug". I should probably stop adding comments which are irrelevant for end users. BTW If you disable refactoring module, you will be unable to rename any package.
Re: "we cannot do refactoring if this package does not exists" The package does exist. IDE just let me create it. The fact that the refacroring infrastructure doesn't know about it is an implementation detail (perhaps a flaw). In theory, I might create an empty package and start adding 'import myeptypackage.*' statements to my sources and then go to refactor/rename it and expect that everything would work.
This kind of discussion does not lead anywhere. There are two meanings of "package": One package is provided by java/project. This package represents folder structure. And other "package" comes from JLS. This package is declared by package statement. (BTW if you do your scenario and add 'import myeptypackage.*' statements. This statements will be marked with error annotation saying, that myeptypackage does not exists - although you've created it in the IDE). Refactoring module unfortunately must work with both terms consistently, which is sometimes almost impossible.
I don't see how the last 5 comments relate to this bug. Rename of empty package is disabled by the projects, it is a known problem (as apparent from previous comments) and should be fixed. Regarding refactoring of empty packages, it is not possible and is as designed. There is nothing to refactor in this case. Although one might argue that somebody can have import mypackage.* in their code and want's it to be renamed, it is an erroneous code and there will be the same number (i.e. zero) of classes imported before and after the rename of mypackage and the compiler/editor will still report the same error about the import statement, so, I don't see the problem.
Just to be picky... > The package does exist. IDE just let me create it. The fact that the > refacroring infrastructure doesn't know about it is an implementation > detail (perhaps a flaw). If you call this a flaw in refactoring implementation, perhaps you should also file an issue against the build system. I've just created an empty package in the IDE (as you say) and imported it by Main class. Compiled that Main class in the IDE and the IDE replied with: Compiling 1 source file to /home.local/martin/JavaApplication16/build/classes /home.local/martin/JavaApplication16/src/javaapplication16/Main.java:9: package empty does not exist import empty.*; 1 error
Martin, let me introduce a scenario :) We have two developers working on same project. Call them Pat and Mat. Pat is responsible for package pat.hnusak and Mat for mat.dulezite Pat is lazy and Mat have already included his package 'pat.hnisak; to be imported (import pat.hnusak.*;) in some classes because he will need to use Pat's classes when Pat will create them. Pat is not only lazy he is a little bit foolish and before he started coding his part of project, he renamed the package 'pat.hnisak' to 'pat.lenivec'. AND to save Mat's time he wants to refactor his code too. Does it really look so strange ? "People are strange" as Jim - the Lizard's king said.
If somebody feels strongly that we should support the scenario presented by Lukas, please file a new enhancement request against refactoring. I will not comment on whether I think it is strange - last couple of days I feel like I am from a different planet. I guess it must be my wedding fever. :)
Lukas' example is a variant of what has been discussed previously. I understand that references to empty packages via 'import xxx.*' cause compile errors and for the same reason empty packages cannot be renamed via refactoring. Let's close this dicussion and focus on the main problem: There's currently no way to rename an empty package in the Projects view.
So as I say, PackageViewChildren is presumably responsible for not permitting an empty package to be renamed. I filed a separate issue #48200 regarding the impossibility of moving the default package, for easier tracking.
I enabled rename refactoring for default package and also for folders, which are not packages, but contain files. Hrebejku, please enable rename action for empty folders: Checking in src/org/netbeans/modules/refactoring/CheckUtils.java; /cvs/refactoring/src/org/netbeans/modules/refactoring/CheckUtils.java,v <-- CheckUtils.java new revision: 1.6; previous revision: 1.5 done Processing log script arguments... More commits to come... Checking in src/org/netbeans/modules/refactoring/api/MoveClassRefactoring.java; /cvs/refactoring/src/org/netbeans/modules/refactoring/api/MoveClassRefactoring.java,v <-- MoveClassRefactoring.java new revision: 1.24; previous revision: 1.23 done Processing log script arguments... More commits to come... Checking in src/org/netbeans/modules/refactoring/ui/RSMJavaDOAction.java; /cvs/refactoring/src/org/netbeans/modules/refactoring/ui/RSMJavaDOAction.java,v <-- RSMJavaDOAction.java new revision: 1.6; previous revision: 1.5 done Checking in src/org/netbeans/modules/refactoring/ui/RefactoringPanel.java; /cvs/refactoring/src/org/netbeans/modules/refactoring/ui/RefactoringPanel.java,v <-- RefactoringPanel.java new revision: 1.15; previous revision: 1.14 done Checking in src/org/netbeans/modules/refactoring/ui/RenameAction.java; /cvs/refactoring/src/org/netbeans/modules/refactoring/ui/RenameAction.java,v <-- RenameAction.java new revision: 1.15; previous revision: 1.14 done Checking in src/org/netbeans/modules/refactoring/ui/RenameRefactoringUI.java; /cvs/refactoring/src/org/netbeans/modules/refactoring/ui/RenameRefactoringUI.java,v <-- RenameRefactoringUI.java new revision: 1.10; previous revision: 1.9 done
What is a rename refactoring for "folders which are not packages but which contain files"?? Isn't that simply renaming the folder?
Let's have folder: "org/netbeans" and a class in it Test.java: package incorrect; public class Test { . . . } User wants to rename org.netbeans to com.netpeas. There is no package org.netbeans defined in source files. But regardless of this fact class Test is moved into new package com.netpeas. But, in most cases it is simply the same as renaming folders.
Checking in project/src/org/netbeans/spi/java/project/support/ui/PackageViewChildren.java; /cvs/java/project/src/org/netbeans/spi/java/project/support/ui/PackageViewChildren.java,v <-- PackageViewChildren.java new revision: 1.36; previous revision: 1.35 done Processing log script arguments... More commits to come... Checking in project/test/unit/src/org/netbeans/spi/java/project/support/ui/PackageViewTest.java; /cvs/java/project/test/unit/src/org/netbeans/spi/java/project/support/ui/PackageViewTest.java,v <-- PackageViewTest.java new revision: 1.15; previous revision: 1.14 done
Fixed rename of a.b.c to a.b Added checking of package name validity Checking in project/src/org/netbeans/spi/java/project/support/ui/PackageViewChildren.java; /cvs/java/project/src/org/netbeans/spi/java/project/support/ui/PackageViewChildren.java,v <-- PackageViewChildren.java new revision: 1.39; previous revision: 1.38 done Processing log script arguments... More commits to come... Checking in project/test/unit/src/org/netbeans/spi/java/project/support/ui/PackageViewTest.java; /cvs/java/project/test/unit/src/org/netbeans/spi/java/project/support/ui/PackageViewTest.java,v <-- PackageViewTest.java new revision: 1.16; previous revision: 1.15 done
v