Community
Participate
Working Groups
If a plugin provides .options file, it is possible to enable tracing for this plugin via General > Tracing preference page. This bug covers adding the org.eclipse.jdt.ui plugin to this preference page to make it easier to debug problems in runtime without restarting Eclipse.
Gerrit review: https://git.eclipse.org/r/#/c/36688/
I think it would be good to adjust the behavior of debug flags so that disabling the general flag (plugin_id/debug) disables all flags (like it is done in other bundles) but this can be done in a separate bug.
(In reply to Szymon Ptaszkiewicz from comment #2) > I think it would be good to adjust the behavior of debug flags so that > disabling the general flag (plugin_id/debug) disables all flags (like it is > done in other bundles) but this can be done in a separate bug. No, it must be 'true' for the ease of the user, otherwise he has to click yet one other checkbox. Plus, when he copy/pastes from the plug-in's .options into the installation's .options file the normal use case is to start debugging, hence 'true' is the correct default. Also note that this option only controls the general debugging mode of a plug-in as per Plugin.isDebugging(). It does not control/override all other options, and we never combined additional options with this general one.
(In reply to Dani Megert from comment #3) > (In reply to Szymon Ptaszkiewicz from comment #2) > > I think it would be good to adjust the behavior of debug flags so that > > disabling the general flag (plugin_id/debug) disables all flags (like it is > > done in other bundles) but this can be done in a separate bug. > > No, it must be 'true' for the ease of the user, otherwise he has to click > yet one other checkbox. That it not how I perceive it. More important than enabling a single option is ability to disable debugging of the whole plugin using only the general debug flag and then enable it back also with "one click". This way you can pre-enable more fine-grained debug options and disable just the main one and then when you observe a problem, with just "one click" you can enable the whole set of previously prepared debug options at the time you need to start printing debug messages. > Plus, when he copy/pastes from the plug-in's > .options into the installation's .options file the normal use case is to > start debugging, hence 'true' is the correct default. This is not about default values in .options files but whether disabling just one flag should disable all of them. Default values in .options are not related here. > Also note that this option only controls the general debugging mode of a > plug-in as per Plugin.isDebugging(). It does not control/override all other > options, and we never combined additional options with this general one. That's not true. In case of many bundles the initialization of debug options used to look like this: static { if (Activator.getInstance().isDebugging()) { DEBUG = true; DEBUG_SYSTEM_PROVIDERS = "true".equalsIgnoreCase(Activator.getInstance().getDebugOption(Activator.ID + "/systemproviders")); //$NON-NLS-1$ //$NON-NLS-2$ } which means you had to enable the general debug flag in .options in order to enable more fine-grained debug options. Hence, they used to depend on the general one. I think that is a very useful pattern that has been used in many bundles across different projects in SDK.
(In reply to Dani Megert from comment #3) But that's not the scope of this enhancement :) The proposed patch does not change the way options are enabled or disabled so if you don't want them to depend on the general debug option, then it's fine for me.
(In reply to Szymon Ptaszkiewicz from comment #4) > (In reply to Dani Megert from comment #3) As said, the intention was not to use "debug" as the main switch. If it were, then - this would be directly wired into the framework i.e. getDebugOption would always check the main switch. This is not the case - the UI would show this dependency. I don't say that some implemented such a dependency on top of it. But as many plug-ins didn't. I'm not arguing to change one or the other, but I'm arguing not to force/change the existing strategy for existing bundles.
(In reply to Szymon Ptaszkiewicz from comment #5) > (In reply to Dani Megert from comment #3) > > But that's not the scope of this enhancement :) The proposed patch does not > change the way options are enabled or disabled The change does change the .options file ;-). I'm currently reviewing the change, so stay tuned!
(In reply to Dani Megert from comment #6) > (In reply to Szymon Ptaszkiewicz from comment #4) > > (In reply to Dani Megert from comment #3) > > As said, the intention was not to use "debug" as the main switch. If it > were, then > - this would be directly wired into the framework i.e. getDebugOption would > always check the main switch. This is not the case > - the UI would show this dependency. > > I don't say that some implemented such a dependency on top of it. But as > many plug-ins didn't. I'm not arguing to change one or the other, but I'm > arguing not to force/change the existing strategy for existing bundles. I fully agree we must not force it. But it never hurts to open a bug and ask project committers for their opinion :) If they agree, I think it's fine to change it.
(In reply to Szymon Ptaszkiewicz from comment #1) > Gerrit review: https://git.eclipse.org/r/#/c/36688/ See my comments in Gerrit. Mainly cosmetic nature.
Submitted with http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=1b13ce6e2dc460ae0f013e8f4bce09d80c82a836
Verified in I20141209-2000.
