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.
Netbeans version 3.3 (build 200112102331) My module's manifest has a declaration of type roots, as follows :- Name: explorerTab/AppRoot.class OpenIDE-Module-Class: Node Type: Roots When I install the module through Open API Support in test mode, the extra tab on the explorer appears correctly. But when the same module is pre-installed with Netbeans, ie., (if the module is copied into modules/.. directory, or to the userDir/modules directory) the extra tab does not appear. The defect is quite critical to our product, as we wanted to ship Netbeans pre- installed with our module. The extra tab provides the main functionality of our module.
Created attachment 4697 [details] An example module file that demonstrates the defect
In fact it does show up - after View | Explorer is selected. Note that the built-in Workplace tab (used when projects module is not installed) also does not show up immediately. When the projects module is installed, the Project tab appears, but not this root. So there is some problem refreshing NbMainExplorer on time. Javadoc module does not suffer from this problem. Turns out it declares a top component ref in the Explorer *in addition to* adding a manifest section. Kale, a workaround would be to copy the stuff Javadoc module does in its XML layer under Windows/ to register its tab. In other words, some rewrite of the window system broke backward compatibility for root node installation from manifest - the tab still appears manually but not automatically. This must be fixed for 3.4 IMHO. I suggest the workaround in javadoc be deleted, and NbInstaller when adding a Node manifest section should autocreate suitable window system XML files on the FixedFileSystem. A proper fix for issue #19609 might be enough to fix this.
Fix of this bug depends on a task that is not implemented yet. A waiver for FFJ 4.0 requested.
IMO the bug could be fixed directly in 3.3.x, without implementing issue #19609 as a whole, but it would be "dead-end" code (effort not usable for 3.4 anyway).
Fix this issue now depends on fix issue 22758 (derived from 19609); should use above recommended workaround about use xml layer under Windows/.
Target milestone was changed from '3.4' to TBD.
Set terget milestone to TBD
This bug is reported in version <= 3.4dev and still not fixed. Due to that it forbids the release candidate for 3.4 to be promoted. Are you aware of that and are you intensively working on the fix? If not, you should consider some corrective action.
I decrease the priority, there is a workaround and this issue depends on task 22758 with P3.
I don't agree with the P3 rating - we broke backward compatibility for manifest installation. That is a bug: a module using this manifest entry would add a node in 3.3, and does not in 3.4, contrary to the documentation in the Nodes/Modules API for 3.3. The fact that restoring compatibility would be done most easily in conjunction with a UI change, which happens to be marked P3, is irrelevant. The fact that you do not plan to fix it for 3.4 is also irrelevant. The workaround is also not really good for most modules because it (1) requires a nontrivial amount of work to implement for a module author and (2) still won't look quite right unless #22758 is implemented for other tabs.
The UI will now look consistent - see issue #22758 and issue #28048.
please Peter, take care about this. thanks
To me it seems it is working, see the issue #22758. Closing as worksforme. Please reopen if you have different result.
NodeSectionTranslator is supposed to be the fix of this, correct?
Yes, correct.
verified - it works fine in [nb_dev](20030728)