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.
Some regular modules neither AutoUpdate-Show-In-Client nor AutoUpdate-Essential-Module org.netbeans.modules.html
AFAIK noone has any dependency to this module. However the module provides the dataloader for html files and some html palette support. So if the module is not installed at least the html editing is not possible for .html files. I think such module is supposed to be regular, but I am not sure what is the right solution of the AU problem. Showing the module to clients is weird IMHO so the only solution is to say the module is essential - AutoUpdate-Essential-Module: true. Please confirm that I understand the problem or correct me if I am wrong. Thanks Jesse
Another solution could be to set show-in-client to false and add a dependency of org.netbeans.modules.editor.kit on this module. BTW, where can I find documentation for these manifest tags? I did not find anything here: http://bits.netbeans.org/dev/javadoc/org-openide-modules/org/openide/modules/doc-files/api.html
The Au-S-I-C is already set to false. The test (and the usecase) requires either AU-S-I-C or AU-Essential-Module set to true or the module to be autoload or eager. Using the editor.kit dependency would work as well. Is there any doc describing the purpose of the module and the situations when it should be used? Some documentation is on http://wiki.netbeans.org/NB6AutoupdateChanges.
Making this a dependency of some kit is very likely the correct solution. The tag is not documented in the Modules API because it is not interpreted by the Modules API; it is interpreted only by the Plugin Manager. NB6AutoupdateChanges is the best available documentation AFAIK.
BTW remember that a kit -> module dep should be runtime only, not compile-time, i.e. no <build-prerequisite/> nor <compile-dependency/>.
yes, runtime dependency of editor kit is the correct solution
fixed in changeset c49bf7e21994
Btw, the dependency to the html and other modules has been removed recently since the modules were moved to gsf cluster and the build failed AFAIK. If I ant clean and build it works on my machine so I commited the change and wait for the build result. If the build fails then we need to find some other solution. Creating new editing kit or moving the old one to gsf are possibilities or moving the kit to ide6.1 folder could help (Yarda said that this option has been refused before some time).
I reverted the change since there are supposely some problems with building the basic ide. I am out of the office today, I'll look at it tomorrow.
The ide build with the editor.kit->html runtime dep. is ok, but if the IDE is built w/o the gsf cluster then it complains about missing html module (dependency from editor.kit) during startup.
Moving the kit to gsf1 seems like the best option. All distributions that use ide9 should now contain gfs1 as well.
It is illegal to have a dep from ide -> gsf clusters currently: nb.cluster.ide.depends=nb.cluster.platform Moving editor.kit to gsf is possible I guess, though it is not clear to me what the intended purpose of this new cluster actually is. Was there some kind of review in which it was decided that a new cluster was warranted for some reason? I am not even clear on what the real meaning of the name is. "Generic Scripting Framework" I thought, but support for HTML lexing and Rhino is not generic in the least. I would expect the JavaScript modules to be put in a "javascript" cluster and everything else put in "ide".
There was pushback from Hrebejk and the editor team against adding friend API (GSF, general scripting framework) into ide cluster. The GSF API is still evolving quite a bit so Hrebejk suggested a separate cluster. The only reason why JavaScript and HTML are in gsf1 cluster is because of dependencies. I think that once the GSF API is stabilized all of its content should be moved into ide cluster. JavaScript could possibly have its own cluster, but I do not a strong motivation for this. Many different distributions will want to include JavaScript. Also JavaScript is just an editor (for now anyway) there are no project types, for example, so it is not very intrusive and should not harm if we just include it into ideX cluster. Compare to HTML.
I have moved the editor.kit to gsf cluster and added a dependency editor.kit->html. I am not sure if any other config files need to be updated, though. http://hg.netbeans.org/main/rev/549ce8ada593