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.

Bug 128750 - Module not available to AU
Summary: Module not available to AU
Alias: None
Product: web
Classification: Unclassified
Component: HTML Editor (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Marek Fukala
Depends on:
Reported: 2008-02-28 19:40 UTC by Jesse Glick
Modified: 2009-05-18 10:45 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2008-02-28 19:40:55 UTC
Some regular modules neither AutoUpdate-Show-In-Client nor AutoUpdate-Essential-Module
Comment 1 Marek Fukala 2008-02-29 08:40:05 UTC
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
Comment 2 Petr Jiricka 2008-02-29 11:39:10 UTC
Another solution could be to set show-in-client to false and add a dependency of org.netbeans.modules.editor.kit on this

BTW, where can I find documentation for these manifest tags? I did not find anything here:
Comment 3 Marek Fukala 2008-02-29 13:03:44 UTC
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
Comment 4 Jesse Glick 2008-02-29 17:40:29 UTC
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.
Comment 5 Jesse Glick 2008-02-29 17:41:22 UTC
BTW remember that a kit -> module dep should be runtime only, not compile-time, i.e. no <build-prerequisite/> nor
Comment 6 Pavel Buzek 2008-02-29 18:12:24 UTC
yes, runtime dependency of editor kit is the correct solution
Comment 7 Marek Fukala 2008-03-03 13:41:57 UTC
fixed in changeset c49bf7e21994
Comment 8 Marek Fukala 2008-03-03 13:56:23 UTC
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
Comment 9 Marek Fukala 2008-03-03 15:34:20 UTC
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.
Comment 10 Marek Fukala 2008-03-03 16:32:15 UTC
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.
Comment 11 Pavel Buzek 2008-03-03 16:46:13 UTC
Moving the kit to gsf1 seems like the best option. All distributions that use ide9 should now contain gfs1 as well.
Comment 12 Jesse Glick 2008-03-03 16:56:53 UTC
It is illegal to have a dep from ide -> gsf clusters currently:


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".
Comment 13 Pavel Buzek 2008-03-03 19:04:31 UTC
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.
Comment 14 Marek Fukala 2008-03-06 16:37:20 UTC
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.