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.
Found in 6.7 RC3 When I check the box next to "Software as a Service" and press the Deactivate button, I am told I need to restart to have it deactivate. When I restart the IDE and check the Plugins dialog, it still has the green checked circle indicating that it is active. I don't see any errors that would indicate a problem...
Forgot to mention, all other plugins that I have tried to deactivate, do so upon restart without issue.
still valid in 6.9 RC1
*** Bug 178463 has been marked as a duplicate of this bug. ***
BTW Java Profiler has the same problem. I found the reason for this: the module websvc.saas.kit specifies the "OpenIDE-Module-Provides" manifest entry: OpenIDE-Module-Provides: org.netbeans.modules.websvc.saas.kit and the java.kit module specifies "OpenIDE-Module-Recommends": OpenIDE-Module-Recommends: org.netbeans.modules.profiler, org.netbeans.modules.gsf, org.netbeans.modules.websvc.saas.kit, org.netbeans.modules.websvc.saas.codegen.java This way java.kit activation triggers saas.kit activation (as well as the Java Profiler activation). May be the module system should handle these relationships. See also J.Tulach's changes: http://hg.netbeans.org/main/rev/4818035ef955
See also Issue #162962 which says that autoupdate can't deactivate recommended module.
Module system is behaving as documented. If you don't want enablement of java.kit to imply enablement of profiler etc. (when present), then delete the OpenIDE-Module-Recommends clause. This header should likely never be used with reference to other kits, and I'm not sure why it was there to begin with.
*** Bug 162962 has been marked as a duplicate of this bug. ***
OK, I can remove it. But what is the reason why the java.kit was recommending the org.netbeans.modules.websvc.saas.codegen.java? I don't believe that it was not intentionally. The change log introducing it: changeset: 121517:4818035ef955 user: Jaroslav Tulach <jtulach@netbeans.org> date: Sat Mar 14 09:43:43 2009 +0100 summary: Making java cluster dependant only on ide and platform. To do that I needed to add few provides/recommends dependencies. The most strange one is turning websvc.saas. codegen.java into autoload and websvc.saas.codegen recommending it. Hopefully this will w ork. Jarda should explain why he needed the strange deps.
Well, it is not that strange. The Java SE distribution seems to contains also websvc cluster. The primary question is: Should it contain this cluster or not? If the answer is yes, it should. Then FoD tries to mimic this dependency. E.g. as soon as you activate anything from JavaSE distribution, it tries to activate the whole JavaSE distribution. However we still want java cluster to be independent on anything else. Hence the recommend tag in manifest. It is just recommendation, nothing will fail in case websvc cluster is missing. Btw. why are you asking me? Have you really looked at http://hg.netbeans.org/main-golden/rev/4818035ef955 Originally there was strong dependency of java.kit on websvc cluster. The changeset just made it voluntary. Find someone else to blame.
First Jardo, I don't blame you. Why I was asking is that I got this issue and I didn't add the recommends there. As I understand from your description if I remove the org.netbeans.modules.websvc.saas.codegen.java as recommended the FoD will not activate the saas, right?
Right. Enabling java would not activate saas.
Thanks Jardo, this is why I've asked you. It seems that I cannot disable the promotes dependency as the "Software as a Service" will not work. Reassigning to Petr Jiricka to decide what he wants, (either the "Software as a Service" will be automatically enabled with java or user will be able to disable it while having java enabled).
It looks, the most rational solution would be to remove this kind of dependency on websvc.saas (cannot speak for java.compiler dependency). I'll ask authors (the former REST guys) about the reason for this dependency.
> cannot speak for java.compiler dependency I've meant java.profiler (issue 162962)
OK, I will remove it. Thanks Milan.
This is the answer from Nam T. Nguyen: ==== I don't recall I did introduce the dependency. My guess is that the dependency is there through indirect dependency from webservice kit. Obviously java functionality dependency on saas.codegen is not desirable. ==== Originally, the java.kit -> websvc.kit dependency was introduced by p.Jiricka (issue 157040). Anyway, I haven't found a reason for this. IMO, the dependency isn't needed. Or, we can wait for Peter to explain.
OK, I will wait for Petr.
(In reply to comment #9) > FoD tries to mimic this dependency. E.g. > as soon as you activate anything from JavaSE distribution, it tries to activate > the whole JavaSE distribution. If this is desired, it is a high-level feature that should be implemented in FoD. Somehow keep a list of "cluster recommendations" such as java -> profiler (etc.) and if enabling a base cluster due to a trigger, try to also enable the other cluster too, if it is installed. (You already enable all kits in a single cluster together if I understand correctly, so this is not a big conceptual change.) From the perspective of both the module system and Plugin Manager, Java Profiler (etc.) is a purely optional addition. > the recommend tag in manifest. It is just recommendation, nothing will fail in > case websvc cluster is missing. Indeed; but the meaning of OIDE-M-R is that if the websvc cluster *is* present, and java.kit is enabled, websvc.saas.kit will be too. That is not the semantics you want here. > http://hg.netbeans.org/main-golden/rev/4818035ef955 > Originally there was strong dependency of java.kit on websvc cluster. The > changeset just made it voluntary. This particular change in fact added deps, not changed the nature of deps, but it is true that there were analogous deps on other kits before. Again my recommendation is that no kit ever -Recommend another kit; this tag may be used to pull in invisible modules only. (Could easily be checked by ValidateUpdateCenterTest.)
I believe that the basic problems are in "the meaning of OIDE-M-R is that if the websvc cluster *is* present, and java.kit is enabled, websvc.saas.kit will be too" Primarily the OIDE-M-R was invented for autoload modules. The primary meaning is to automatically enable autoload modules that provide the token if one wants it, but don't fail if there is no such module. Note1: In case a module providing token required by another OIDE-M-R is not autoload and is disabled, module system will not enable it (at least I hope). Note2: kits are not autoloads. The original description of the meaning is imho a derived interpretation of the primary meaning for purposes of autoupdate. It is indeed OK if enabling a module with OIDE-M-R enables modules providing that token if present. It is not OK if enabling OIDE-M-R means downloading module providing that token from the net. In the same lines: it is OK to disable module providing a token still OIDE-M-R by another module. Autoupdate shall allow it and module system shall respect it.
>it is OK to disable module providing a token still OIDE-M-R by another module. Jardo, but this issue is about the fact that this does not work. When you disable the SaaS module (providing token) the java.kit (OIDE-M-R) reenables it.
> I believe that the basic problems are in "the meaning of OIDE-M-R is that if the websvc cluster *is* present, and java.kit is enabled, websvc.saas.kit will be too" Yes, you're right. To explain: websvc.saas.kit(cluster) contains functionality(modules) related to Services tab -> Web Services node, like - node contents, actions - code generation API - code that's generated into java/php/ruby sources after Drag&Drop (websvc.saas.codegen) Modules from websvc.saas.kit are independent from modules from java.kit, and vice versa. However, there is a module websvc.saas.codegen.java, implementing websvc.saas.codegen, that is in java cluster (not in java kit). Thus java cluster de-facto depends on websvc cluster.
I wanted to say that there is no sense for java.kit to trigger websvc.saas.kit activation. What about the following entry in java.kit manifest: OpenIDE-Module-Recommends: org.netbeans.modules.websvc.saas.codegen.java Should this be moved into some module from java.kit ? I tend to agree with Jesse: Recommends tag shouldn't be used with kits.
Petre, can you explain the dependency? Can we remove it?
I don't remember now why I added the dependency. I guess it can be removed.
OK, I am going to remove it. Thanks Petre.
The OpenIDE-Module-Recommends removed as Jesse-Recommends. jet-main 95090b0bb55e
Integrated into 'main-golden', will be available in build *201006230001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/95090b0bb55e User: Tomas Zezula <tzezula@netbeans.org> Log: #167382:Software as a Service Plugin won't deactivate
Removing OpenIDE-Module-Recommends: org.netbeans.modules.profiler, org.netbeans.modules.debugger.jpda.ui from java.kit was probably not really good idea. ergonomics#40b995a7f8ed
(In reply to comment #28) > Removing > OpenIDE-Module-Recommends: org.netbeans.modules.profiler, > org.netbeans.modules.debugger.jpda.ui > from java.kit was probably not really good idea. Why? These are both kit modules which depend on java.kit, so your change probably regressed this fix for the case of those two modules - i.e. you would not be able to disable Java Debugger or Profiler while leaving Java on.
Maybe I should enhance ValidateModulesTest to verify that there are no kit-to-kit -Recommends deps? Or that kits do not recommend anything, since they could be recommending some invisible module depending on another kit?
(In reply to comment #29) > > OpenIDE-Module-Recommends: org.netbeans.modules.profiler, > > org.netbeans.modules.debugger.jpda.ui > i.e. you would > not be able to disable Java Debugger or Profiler while leaving Java on. Well, that is basically it. People who enable Java want Java Debugger and Profiler. If there is anything to fix, then we shall probably include java debugger and profiler into java.kit. They are natural part of Java support.
(In reply to comment #31) > People who enable Java want Java Debugger and Profiler. Perhaps they do, but that should be left as an option. In the setup you just committed, these effectively do not function as independent kits at all, which is an anomalous state - Plugin Manager displays the apparent option to turn off e.g. Profiler but it will not actually work. Please revert this dangerous change until there is some consensus; otherwise I need to reopen this bug with a slightly different summary and assign to you. > we shall probably include java debugger and profiler into java.kit. At least the second part is impossible currently, as profiler is in a "higher" cluster.
Integrated into 'main-golden', will be available in build *201008210001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/40b995a7f8ed User: Jaroslav Tulach <jtulach@netbeans.org> Log: Improving #167382: Continue to recommend org.netbeans.modules.profiler, org.netbeans.modules.debugger.jpda.ui