Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 136361 - Mark modules which were disabled by NbInstaller
Mark modules which were disabled by NbInstaller
Status: RESOLVED WONTFIX
Product: platform
Classification: Unclassified
Component: Module System
6.x
All All
: P3 (vote)
: TBD
Assigned To: Petr Nejedly
issues@platform
: API, API_REVIEW_FAST
Depends on:
Blocks: 135512
  Show dependency treegraph
 
Reported: 2008-06-03 12:26 UTC by Jiri Rechtacek
Modified: 2010-10-07 14:37 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jiri Rechtacek 2008-06-03 12:26:14 UTC
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.
Comment 1 Jesse Glick 2008-06-04 06:08:39 UTC
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).
Comment 2 Jiri Rechtacek 2008-06-04 11:03:06 UTC
> 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.
Comment 3 Jaroslav Tulach 2008-06-05 19:35:20 UTC
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.
Comment 4 Jesse Glick 2008-06-12 03:23:46 UTC
"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".
Comment 5 Jesse Glick 2010-10-07 14:37:21 UTC
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).


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo