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
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:
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
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 ***