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.
If any module could not be install into NetBeans application, an user can decide whether Disable&Continue or Exit launching and fix by hand. If Disable&Continue, NbInstaller forces disabling such modules thus module have be enable enabled manually when theirs dependencies could be satisfy. Would be worthwhile to mark such modules in the module status xml file with this state to distinguish module forced to be disabled or disabled by nature (ie. on user's demand). I'll propose a new attribute "disabled_by_module_system" in Module Status DTD for flag that state. NbInstaller declare this attribute if and only if the module should be loaded but could not be.
So is this an API review or not? [JG01] I might suggest making no API change and instead marking the module eager, which would have the effect of turning it on as soon as it can be. [JG02] I would rather suggest not doing this at all. The Plugin Manager should not install a module which could not be enabled to begin with - then we would not run into this situation. It is anyway not clear what the PM will show when some hidden module is disabled (rather than a kit module as such).
> So is this an API review or not? I thought I send to apireviews@ later but let's consider that a API review. > [JG01] I might suggest making no API change and instead marking the module eager, which would have the effect of turning > it on as soon as it can be. Do you think the NbInstaller (or a other class in core.startup) can change the module to be eager? Or module owner should do it by hand? > [JG02] I would rather suggest not doing this at all. The Plugin Manager should not install a module which could not be > enabled to begin with - then we would not run into this situation. Yes. I agree with you. The Plugin Manager could avoid this situation (issue 136269). But it won't be enough. Picture this: an user is used to run IDE on full JDK and then is running JRE only. Some modules become disabled and that's point why pay attention to. > It is anyway not clear what the PM will show when > some hidden module is disabled (rather than a kit module as such). PM while install a new plugin, inspects modules starting visible and then deeply to hidden modules and let to know users about broken dependencies in whole subtree.
Imho, eager is not good: It is "temporary eager" - e.g. enable asap, but then change back to regular. So the user can manipulate with it.
"a user is used to run IDE on full JDK and then is running JRE only" - why would anyone do this? Because they made a mistake in their IDE startup configuration, I guess. So currently we show them a dialog and prompt them to exit as the default button, which they should accept - so they can restart on the JDK. The situation of having forcibly disabled modules could arise in some other fairly obscure cases - e.g. Ubuntu package containing enterprise cluster was deleted and on next start profiler.enterprise (in profiler cluster) cannot be loaded. (Let's just pretend that this is a regular module - more likely it would be eager and thus not need to be disabled.) So still consider this a pretty low priority. But if the new attribute is needed, I would suggest "forcibly-disabled".
I don't think we want to do this. If we make any changes to module enablement configuration, we should do a real overhaul (http://wiki.netbeans.org/ModuleSystemModestProposal gives an example).