Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 151116 - Renaming module package does not update OIDE-M-L-B
Renaming module package does not update OIDE-M-L-B
Status: RESOLVED DUPLICATE of bug 222788
Product: apisupport
Classification: Unclassified
Component: Refactoring
6.x
All All
: P3 with 1 vote (vote)
: TBD
Assigned To: Martin Kozeny
issues@apisupport
:
: 194677 196310 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-23 10:45 UTC by ivan
Modified: 2013-06-19 09:11 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ivan 2008-10-23 10:45:44 UTC
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.
Comment 1 Jana Maleckova 2008-10-23 20:34:18 UTC
reassign to refactoring for evaluation
Comment 2 Jesse Glick 2008-10-24 18:51:58 UTC
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.
Comment 3 ivan 2008-10-24 20:53:31 UTC
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?





Comment 4 Jesse Glick 2008-10-24 22:40:51 UTC
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.
Comment 5 rmichalsky 2008-11-22 22:05:57 UTC
(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 ***
Comment 6 Jesse Glick 2011-03-15 22:23:26 UTC
(b) is not a duplicate of bug #72275, which was something else. Public packages are covered by bug #144150.
Comment 7 Jesse Glick 2011-04-20 18:00:48 UTC
*** Bug 196310 has been marked as a duplicate of this bug. ***
Comment 8 mienamoo 2011-09-12 09:50:00 UTC
Part b) (builds of the module fail dues to bad bundle file references) is still present in build 201109080600 (NetBeans 7.1 dev).
Comment 9 Jesse Glick 2012-01-03 22:48:04 UTC
*** Bug 194677 has been marked as a duplicate of this bug. ***
Comment 10 Martin Kozeny 2013-06-19 09:11:13 UTC

*** This bug has been marked as a duplicate of bug 222788 ***


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo