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.
[ BUILD # : 201109110600 ] [ JDK VERSION : 1.6.27 ] Hi, the module rename action is not working as I expect. The "module rename" window is asking for new project name (which is correct) showing the old DISPLAY name (while it should show the old PROJECT name). In other words the window assume that PROJECT name = DISPLAY name which is not always true. In my test case: Project name is "test-module" Project folder is ".../test-module" Code Name is "com.test.testmodule" Display name "First test-module" In the attached picture the proposed Project name is "First test-module" (Wrong or at least confusing because it is the display name). Moreover if I rename the module which a new name, the Code Name is still the old one and so the generated JAR file which gives, at the end, an inconsistent situation : - Module name = new name - Code name = old name - Generated JAR file : old name I think also the code name and JAR file name should be updated by "module rename" action. Gualtiero
Created attachment 110640 [details] Picture 1
(In reply to comment #0) > The "module rename" window is asking for new project name (which is correct) > showing the old DISPLAY name (while it should show the old PROJECT name). > > In other words the window assume that PROJECT name = DISPLAY name which is not > always true. No; if you leave the checkbox unchecked, you are merely adjusting the display name. If you also opt to move the project's folder, currently it asks for only one name and uses that for both display name and folder name (of course you could later adjust the display name to something else). Could offer both names as separate fields, as in Maven projects, though this would require a specialized dialog - probably not worth the effort. > if I rename the module which a new name, the Code Name is still the > old one Code name base rename refactoring is not supported and probably never will be. The metadata of every other module with a dependency on this one would have to be updated. And if you have ever released this module to users, you should not modify its CNB, or updates will not work.