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.
> I changed module name in manifest from bla.api.bla > to bla.blaapi. Now I get DuplicateException caused > by fact that under system/Modules remains the old > entry. Manual erasing helps. [jglick] Generally changing module code names is not supported and should be avoided if at all possible. I am not exactly sure how a DuplicateException would arise from it though. File a bug if you want. I prefer renaming module manifest entry over renaming it's jar too. I have not seen any harm except the exception => ENHANCEMENT.
Details please - what exactly did you rename and how? And when did you get the exception? Using AU, or part of a regular build? Etc. Need steps to reproduce what happened to you in order to understand what the problem is.
I renamed org.netbeans.api.tasklist/1 to org.netbeans.modules.tasklistapi/1. I deployed using cp tasklist-api.jar ../nbbuild/netbeans/modules/autoload. Then I got the exception during every startup until I removed stalled Modules/org-netbeans-api-tasklist.xml.
I have seen it too. Probably a result of renaming the code name base of some tasklist module, which is definitely not a good idea in general. When I have a moment I will look at making the handling more robust. Might have to wait until a planned change for the future to canonicalize all module JAR names and remove autoscanning of modules/*.jar, but this would be a fairly high-impact change.
When all module JARs have fixed names, you will not be allowed to rename one thing independently and there should be no possibility of a DuplicateException. Anyway changing a module code name base is *never* recommended.
The intent was to reuse existing jar (name). I was unsure how could I declare that some jar name was discontiued (and should be erased e.g. on jar name and a manifest entry match). Reopening with changed synopsis rename => remove.
There is no particular means of forcing a given module to be removed, other than intentionally breaking compatibility of something it depends on. (I.e. depends on behavior of AU client.) Anyway in the case that triggered this, you were trying to rename a module, not remove it, AFAICT.
Actually I wanted to remove the jar. To avoid possible problems with stale jar. I decided to "reuse" the archive for another module. In past I did the same with parser.jar. In this case it was replaced by empty jar.
As of D, you will not be able to choose the JAR name - it will be determined by the module code name base and it will be impossible to override that name. Re. supporting removal of a module through some kind of trick like this - not supported now, no particular plans to support in the future. Leaving open, pending a specific set of use cases etc.
Referring to my previous comment: nothing has come up, so closing for now.