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 189784 - Plugin Manager does not honor the user's request to deativate recommended module
Summary: Plugin Manager does not honor the user's request to deativate recommended module
Status: VERIFIED WONTFIX
Alias: None
Product: platform
Classification: Unclassified
Component: Autoupdate (show other bugs)
Version: 7.0
Hardware: Other Linux
: P2 normal (vote)
Assignee: dlipin
URL:
Keywords:
Depends on:
Blocks: 189779
  Show dependency tree
 
Reported: 2010-08-23 19:31 UTC by Jaroslav Tulach
Modified: 2010-09-20 20:33 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2010-08-23 19:31:35 UTC
Detected few times already. The ergonomics use a lot of OpenIDE-Module-Recommends. However Plugin Manager treats these dependencies as strongly necessary and in spite there is a manual request to disable one of recommended modules it still keeps them on.

Observed first as bug 167382. Its fixed caused bug 189026. Jesse does not agree with the fix and reported bug 189779. I'll be changing it to P3 daily, but I don't think Jesse will let this be without some P2...

Imho, the problem is in autoupdate. If there is a regular module and user wants to disable it, no OpenIDE-Module-Recommends shall prevent that.
Comment 1 Jesse Glick 2010-08-23 19:39:44 UTC
Module management is behaving as designed. The bug is the use of OIDE-M-Recommends, as previously discussed; this is not permissible with kits.
Comment 2 Jaroslav Tulach 2010-08-23 20:55:28 UTC
If there are two regular modules M1 and M2. If M1 recommends M2. Both are enabled. Then calling:

moduleManager.disable(M2);

has to succeed and the assert !M2.isEnabled() has to succeed too. If Jesse is claiming this is not the actual behaviour I am fine with writing a unit test and insist on module system to be fixed.
Comment 3 Jesse Glick 2010-08-23 22:26:54 UTC
That is not the behavior, and no change in this area will be made. -Recommends is identical to -Needs with the exception that if the recommended token does not exist in the module universe the recommendation will be ignored. If it does exist, the behavior is the same as -Needs.

This has all been discussed already in another issue. The resolution was to never use -Recommends with kits.
Comment 4 Jaroslav Tulach 2010-08-24 12:39:02 UTC
Have a look at the test in core-main#7e83d6233d0a

It clearly shows that recommending a token is not reason for preventing manual user disablement of the providing module. In this respect "recommends" is quite different to "needs" (you could not disable m1 in the test if it was "needed").

Now, when we made the first step towards understanding that recommends indeed works for regular modules the way ergonomics need it, we can start discussing what is the problem with kits. As far as I know kits are regular modules and thus I expect them to behave as the test shows.
Comment 5 Jesse Glick 2010-08-24 14:53:19 UTC
Kits behave no differently and the test is checking something different than is relevant here. The difference is that after Plugin Manager requests apisupport.kit be disabled, along with other modules, on next startup the module system is asked to enable modules which are marked for enablement, including java.kit. Since java.kit recommends apisupport.kit, both are turned on.

Again - do not use OIDE-M-Recommends between kits; there is no need for it and it breaks Plugin Manager usage. FoD can do whatever it likes when initially turning on some modules, choosing sets of features by any algorithm that provides a pleasant user experience, so long as it does not interfere with later operation of the module system by introducing bogus dependencies.
Comment 6 Quality Engineering 2010-08-25 03:22:31 UTC
Integrated into 'main-golden', will be available in build *201008250001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/7e83d6233d0a
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #189784: Test showing that regular modules which provide token recommended by active module can be disabled
Comment 7 Jaroslav Tulach 2010-08-31 13:28:04 UTC
If I start Full IDE with ergonomics and enable apisupport.kit, then shutdown.

I can find $userdir/config/Modules/org-netbeans-modules-java-source.xml and modify it to be enabled=false. 

However if I restart, the module system silently turns the module back to enabled state. I don't like that behaviour, but at least it is consistent which the Needs and Recommends one.
Comment 8 Jesse Glick 2010-09-20 20:33:36 UTC
(In reply to comment #7)
> if I restart, the module system silently turns the module back to
> enabled state. I don't like that behaviour

It's not ideal. Unfortunately the current format for persistence of module enablement state has redundancies, especially after the introduction of Plugin Manager in 6.0 made the user-visible state more coarse-grained. http://wiki.netbeans.org/ModuleSystemModestProposal has some discussion.