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.
If you rename the "primary" package of an NB module, the codename base that correlates to it doesn't change. The most evident result of this is ... a) the module name shows up as it's CNB in the project explorer. b) builds of the module fail dues to bad bundle file references. (a) is in fact a side-effect of (b) because the user-visible module name is encoded in the bundle file which is now sitting in the renamed package while it's referred to via the unaltered CNB. I po that "primary" package renames are not that uncommon in the early stages of a project as a contributor gets the hang of NB project/pkh naming conventions and finalizes their projects structure. In nothing else, there's always the transition from org.netbeans.<project>.modules.api to org.netbeans.api.<project> and that's not going to go smoothly. After renaming a "primary" pkg I've found that at least the following files retained the old pkg name and had to be manually adjusted: build.xml <project name/description manifest.mf nbproject/project.xml <code-name-base> <public-packages> nbproject/build-impl.xml The impact of such a rename on the referants to the renamed project is even more extensive. Their dependencies often have to be re-done by hand.
reassign to refactoring for evaluation
Part (b) sounds like a bug; if you rename the package containing the module's localizing bundle, the OpenIDE-Module-Localizing-Bundle attribute in the manifest ought to be changed. Similarly, if you rename a package mentioned in <public-packages> in project.xml, the mention ought to be renamed as well. For external (non-nb.org) modules, the CNB displayed in build.xml and build-impl.xml should be adjusted automatically if you edit the CNB in project.xml and reopen the module project. As to the rest, there has never been any support for mechanically renaming a module's CNB. (The name of the "primary" package in the module, if there even is such a thing, has no necessary relation to the CNB, so please do not confuse the two.) This would be nontrivial to implement (consider references from other modules...). I'm not sure it is even a good idea, as changes to the CNB of a module which has already been deployed are not generally possible (you break the upgrade path and potentially many other things), so such a refactoring could be used only on modules which had never seen a public release.
The correlation established by the IDE between the package name and the CND is _so strong_ that one can't help but relate the two. Because of this, the fact that the cnb is not editable initially led me to believe that it tracks the pkg name. The need to change the cnb is strong _exactly before_ a module has been released. It took me a fair amount of analysis to grok the naming patterns used in NB ... the relationship between module name, package name and cnb name is not clear by a simple 'ls'ing of the main repository. It also took me a fair amount of time to decide on good pkg names as the API "balloon" got shoved here and there. If anything, there is the typical start the pkg as org.netbeans.api.project, find out that it should be org.netbeans.modules.project.api, rename it, then eventually rename it to org.netbeans.api.project again. How may times has it been asked: why is the pkg name diferent from the jar file name? Could it be that people chose better pkg names but couldn't change their jar file names easily? When I suggested a library "purity" switch you noted that api reviews can control it. api reviews should be able to control changes to the CNB as well so I think "it's not a good idea" is not much of an excuse. Now that it's clear that cnb and pkg name aren't related. The issue of this bug becomes simpler: allow renaming of the cnb. I suppose that's a separate IZ?
The project subdirectory name for a netbeans.org module is strictly determined by the CNB as of NB 6.1. The JAR file name is also derived from the CNB, and it crops up in various places in build products. There is no strong correlation between CNB and package names. (For that CNB to "track" the "main" package name is a logical impossibility, as there could be any number of packages with unrelated names in the module.) While the new module wizard uses the CNB as a default name for an initial package in which to dump e.g. a localizing bundle, that is about it. Very often a module is named org.netbeans.modules.foo and while it may have a package by that name as well, org.netbeans.api.foo, org.netbeans.spi.foo, etc. are also common, and of course there can be "subpackages" like org.netbeans.modules.foo.something. In some cases the package names used are rather different from the CNB, generally for historical reasons. CNB refactoring is already covered by issue #71277. (Clearly it would need to be accompanied by a stern warning not to proceed if the module had already been released into the field.) Updating summary accordingly.
(b) is also already tracked as issue #72275, closing as duplicate (of one of the two issues). *** This issue has been marked as a duplicate of 72275 ***
(b) is not a duplicate of bug #72275, which was something else. Public packages are covered by bug #144150.
*** Bug 196310 has been marked as a duplicate of this bug. ***
Part b) (builds of the module fail dues to bad bundle file references) is still present in build 201109080600 (NetBeans 7.1 dev).
*** Bug 194677 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 222788 ***