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.
Refactoring a directory which is part of a module via: rt popup->refactor->rename of directory does not push through the name change to at least the following files which use the folder name: 1 manifest.mf 2 build.xml <project name="name is now wrong" <description = description is now wrong Sorry I could not locate the refactoring bug-report place to submit this to. It's not so much an IDE / UI issue.
by directory do you mean the project's own folder? more detailed steps to reproduce would help.
It probably means changing package name (codeNameBase), in which is located Bundle.properties does not affect Manifest.mf (OpenIDE-Module attribute and OpenIDE-Module-Localizing-Bundle attribute) and project.xml (tag project and its attribute name and child description tag).
Refactoring results are now pushing through manifest and other project's property files. https://hg.netbeans.org/core-main/rev/87a814de9df8
Integrated into 'main-golden', will be available in build *201306142301* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/87a814de9df8 User: Martin Kozeny <mkozeny@netbeans.org> Log: #222788: Refactoring results are now pushing through manifest and other project's property files.
*** Bug 151116 has been marked as a duplicate of this bug. ***
I guess the addition of nbbuild/misc/hints-settings.xml was irrelevant to this commit. Changing the codeNameBase is drastic and should never be done without a proper warning: this will orphan any existing installations of the module and prevent a proper upgrade, not to mention breaking any downstream modules. While this might be appropriate if you have just created a new module and changed your mind about naming, it should never be done on production code. (Changing the package names inside the module, if they are not exported as APIs, is generally harmless, though you might need to add an entry to META-INF/netbeans/something.here which I forget the exact name of but which lets you change package/class names while preserving deserialization compatibility.)
(In reply to comment #6) > I guess the addition of nbbuild/misc/hints-settings.xml was irrelevant to this > commit. You are right, it was removed later from the repository. > Changing the codeNameBase is drastic and should never be done without a proper > warning: this will orphan any existing installations of the module and prevent > a proper upgrade, not to mention breaking any downstream modules. While this > might be appropriate if you have just created a new module and changed your > mind about naming, it should never be done on production code. Maybe the best solution would be to disable renaming of codeNameBase.. > (Changing the package names inside the module, if they are not exported as > APIs, is generally harmless, though you might need to add an entry to > META-INF/netbeans/something.here which I forget the exact name of but which > lets you change package/class names while preserving deserialization > compatibility.)
I mean disable renaming package standing for codeNameBase.
*** Bug 189503 has been marked as a duplicate of this bug. ***