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.
#20020419 The icons for contents and help sets have changed. Now there are xml icons instead of '?'.
Only happens when XML module is installed. Maybe you fail to ask the filesystem for icon annotations correctly.
What is icon annotation? How could XML module change icons for helpsets when it is explicitly set in manifest layer? Thanks.
The layer sets SystemFileSystem.icon attribute. The system filesystem interprets this in its FileSystem.Status implementation. A DataNode is supposed to call Status.annotateIcon to get its icon. And looking in the default filesystem in the running IDE, non-*.xml files with icon annotations appear correctly, but the .xml files in the Menu/Help/ dir and subdirs do not appear correctly. It is fixed when XML Core is disabled. So probably the nodeDelegate for org.netbeans.modules.xml.core.XMLDataObject is not correctly asking the filesystem for icon annotations.
I do not think XML module should care about SystemFileSystem attributes. If you do not like it is caught by XML module you should set for it default o.o.l.XMLDataObject's Loader (named "XML Configuration Files").
I don't like to get this issue closed. The XML icons doesn't look nice in the help menu and moreover this isn't wanted change, we can look at it as at regression. Please reasign instead of closing.
Core should set default XML loader for files in system folder or change extension for files which should not be recognized by XML module.
I'm sorry, I still have to disagree. XML module has the responsibility to *not recognize* files in the system filesystem if it cannot treat them correctly! Here "correctly" means "at least as well as org.openide.loaders.XMLDataObject", i.e. that the data node ought to acknowledge the existence of FileSystem.Status icon annotations, as all other data nodes do, and honor them. The same would be true of e.g. CVS up-to-date marks (just a guess - please check), i.e. the module does *not* need to know specifically about SFS.* attributes. Adding the XML Core module ought not break functionality present in the platform code.
DataObject's createNodeDelegate() JavaDoc says that implementation has to return a Node. No other constrain is mentioned. Consequently if core really needs to force some special behaviour for some data objects representing special file objects on special filesystem let it takes care of it.
[marking P2: clear regression] OK... Yarda, since XML module will not fix its node to annotate icons (note: may still need to file UI bug for interaction with CVS), do you think the org.openide.loaders.XMLDataObject loader ought to be moved to the top of the loader pool and made to only accept files on the system filesystem? Note that XML module templates will then appear with the openide loader, which may mean that after being created from template they are still openide XML objects (I never liked that MultiDataObject.createFromTemplate behavior). It would probably also bust Ant scripts. That would be a P1 regression I guess. Accepting SFS files but excluding Templates/ will not work - consider pleasantly localized Templates/Services/ objects, they would be broken. I guess we could "float" the openide loader in the loader pool (not make it fixed); make it recognize only SFS files; have XML Core loader declare that it comes *after* the openide loader, and Ant loader (etc.) *before*; and if the XML Core module wants to continue working it will need to use the NetBeansAttrAssignedLoader file attribute to get called first in some cases (e.g. on its template *.xml files). Anyone see problems with this? BTW we should probably add to DataObject.createNodeDelegate Javadoc: "Implementations are *strongly recommended* to produce a node which will honor any annotations supplied by FileSystem.Status, as DataNode does."
*** Issue 22556 has been marked as a duplicate of this issue. ***
"floating" means just to add it as regular loader and tell people to use Install-After, Install-Before logic. I think that should work and I do not see any problem with that.
-> phrebejk
Just rephrasing summary to reflect the actual problem... While we're at it, it seems that you need the XML Tree View module installed to trigger the bug, I think.
See also issue #23222.
Lowering priority as the issue #23222 is fixed and the visible symptoms are no longer pertinent. Reasignig to loaders as this is a datasystem issue. And should be solved at least when redesigning loaders.
I think that Dafe has a patch for XML module that seems to solve this problem by refusing to recognize files on system file system if they do not have DataLoaderPool.setPreferredLoader.
yes, patch is attached to http://www.netbeans.org/issues/show_bug.cgi?id=24766 integrating patch should also solve this issue.
solved together with 24766 helpsets are now loaded via openide XML loader, resulting in openide XML data object creation.
*** Issue 21250 has been marked as a duplicate of this issue. ***
verified in [nb_dev](20020627)
Resolved for 3.4.x or earlier, no new info since then -> closing.