Hi Chris,
What about if the PreferenceInitializer for codan was changed
so that all checkers are disabled by default. That way, a user
would have to deliberately enter the codan preferences and select
problem checkers for them to be enabled...
Antony
On 08/04/2013 15:55, Chris Recoskie wrote:
I think perhaps we should look
at things a bit differently. You shouldn't have to "turn off"
Codan. My opinion is that it should only be enabled if you
"turn it on." E.g. with other parts of CDT like various
builders, etc., you don't get them unless you set something on
your project that enables them. You should only get Codan on
your project if you ask for it.
If we leave it so that you
always get it even if you didn't ask for it, we force all the
clients to have to deal with it even if they don't know or
care about Codan. We'll forever be playing Whack-A-Mole
trying to stomp out instances where someone forgot to turn it
off (or if the way you have to turn it off changes and the old
way of turning it off no longer turns it off).
CDT turning it on by default
via the CDT project wizard is for me at least not a big deal
as our team writes our own project wizards that omit anything
we don't want. I don't think I should have to write code to
turn it off though. If I don't want it then I should be able
to just not write any code that turns it on.
Right now the current situation
is a mess. The "solution" to turn it off is long and involved
and there are many cases where it can fail.
To turn it off I have to:
1. Turn off all Codan checkers programmatically. This apparenly doesn't
always work, so additional steps are required (see next
steps).
IEclipsePreferences codanp =
CodanCorePlugin.getDefault().getStorePreferences();
// get problem checker
keys
String[] keys = null;
try {
keys =
codanp.keys();
} catch
(org.osgi.service.prefs.BackingStoreException e) {
// TODO
Auto-generated catch block
e.printStackTrace();
}
// first disable all
problem checkers...
for (int i=0; i<keys.length; i++) {
String res =
codanp.get(keys[i], "");
if
(!res.substring(0,1).equals("-")) {
res = "-"+res;
}
if
(res.equals("-Error") || res.equals("-Warning") ||
res.equals("-Info")) {
codanp.put(keys[i], res);
}
}
2. Do not ship the Codan plugins in your product, as #1 is not
guaranteed to work, and #3 only works for new workspaces.
3. In case the Codan plugins do ever get installed (e.g. user runs
the update manager manually, or shell-share installs another
product into yours that installs Codan), put the following in
your product's .ini file:
org.eclipse.ui.workbench/PLUGINS_NOT_ACTIVATED_ON_STARTUP=org.eclipse.cdt.codan.ui;
This will prevent Codan from being loaded in new workspaces (if the product
is launched with your .ini file). Unfortunately there is no
good solution to keep it from loading on existing workspaces.
Unfortuantely this also means that if you launch the same
install but with another product's .ini file, Codan will get
loaded and then your workspace is now tainted with Codan.
4. Hide all Codan UI using activities, so that hopefully you can never
activate the plugin manually. However, if you also shell
share with other products that want Codan there, you have to
only hide these in certain circumstances, in which case it
could get activated again, and in this case I'm not sure what
you can do. Nothing it seems.
===========================
Chris Recoskie
Team Lead, IBM CDT and RDT
IBM Toronto
Antony Burton ---04/08/2013
08:44:23 AM---OK will try with empty workspace. Yes, you're
right, the global toggle code should live in the codan
From: Antony Burton
<aburton@xxxxxxxxxxx>
To: "CDT General developers list."
<cdt-dev@xxxxxxxxxxx>
Date: 04/08/2013 08:44 AM
Subject: Re: [cdt-dev] Problem
Enabling/Disabling Codan checkers programmatically (Bug?)
Sent by: cdt-dev-bounces@xxxxxxxxxxx
OK will try with empty workspace.
Yes, you're right, the global toggle code should live in the
codan plugin and I would love to contribute but have not done
that before... I will look into it next week when I'm less
busy...
Thanks again,
Antony
On 08/04/2013 12:29, Oberhuber, Martin wrote:
Hi Anthony,
Regarding my
method, if you try with an empty workspace it should work (
-pluginCustomization xyz.ini –data /tmp/empty).
Regarding your
method, if you current code for “disable all” lives in the
codan plugin itself rather than your external plugin, then the
“who starts first” should not be an issue.
A
PreferenceInitializer might be needed to run your code when
somebody first tries to read one of the codan prefs (to ensure
that your “global toggle” is observed).
I’d love to see
your global toggle in the Codan Preferences UI.
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product
Architect – Development Tools, Wind River
direct
+43.662.457915.85 fax +43.662.457915.6
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Antony Burton
Sent: Monday,
April 08, 2013 12:17 PM
To: CDT General
developers list.
Subject: Re:
[cdt-dev] Problem Enabling/Disabling Codan checkers
programmatically (Bug?)
Hi Martin,
Thanks for your reply. I tried your idea but it doesn't work
for me. What I did was to create a plugin_customization.ini
file with the command:
org.eclipse.ui.workbench/PLUGINS_NOT_ACTIVATED_ON_STARTUP=org.eclipse.cdt.codan.ui;
...and then add:
-pluginCustomization plugin_customization.ini
to the eclipse.ini file. I must be doing something wrong.
Could you please explain in detail?
After all though, I would prefer to do it programmatically
as I do because I would like more control over
enabling/disabling problem checkers either individually or
globally. Note that the first part of my method disables all
problem checkers whilst keeping all default severities. So
it would be easy to turn CODAN on and off whilst using
default values. We could easily go further and also save
current enable/severity settings so that CODAN could be
switched on or off with one switch conserving current
settings. This would fulfil your initial request in:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=374749
The only problem is that when entering a new workspace,
before CODAN preferences can be set programmatically, it is
necessary to go into:
Windows -> C/C++ -> Code Analysis
and click on the "Apply" or "Ok" button at least one time.
Is there no way get around this? A way of doing what the
"Apply" or "Ok" buttons do programmatically?
Thanks again,
Antony
On 05/04/2013 14:38, Oberhuber, Martin wrote:
Hi Anthony,
Instead of enabling/disabling
each checker separately, what we have done in our product
is disable the "autostart" of Codan as a whole:
Preferences
> General > Startup : Plugins not enabled on startup
: CODAN
We do it by putting this into
our plugin_customization.ini :
org.eclipse.ui.workbench/PLUGINS_NOT_ACTIVATED_ON_STARTUP=org.eclipse.equinox.p2.ui.sdk.scheduler;org.eclipse.update.scheduler;
org.eclipse.cdt.scripting;org.eclipse.dltk.ui;org.eclipse.php.debug.daemon;org.eclipse.cdt.codan.ui.cxx;org.tigris.subversion.subclipse.tools.usage;
This works nicely in NEW
workspaces; the only problem is that if user has an
EXISTING workspace where the respective
PLUGINS_NOT_ACTIVATED_ON_STARTUP has been set in the
workspace preferences while Codan was not yet installed
(in an earlier release), the new plugin_customization.ini
is not picked up.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=374749
Another disadvantage is that
once user does Right-click > Validate on a project,
CODAN is enabled (and remains enabled). But since that is
an explicit request to turn on validation, it could also
be seen as an advantage. Another advantage of our approach
is that IF a user DOES want to use codan, it is a single
switch to change and not all of them.
The best solution would be
fixing the bug mentioned above, ie introducing a global
CODAN on/off switch in addition to all the individual
checker switches.
Implementing this shouldn't be
rocket science...
Contributions welcome :)
Thanks,
Martin
--
Martin Oberhuber, SMTS /
Product Architect – Development Tools, Wind River
direct +43.662.457915.85 fax
+43.662.457915.6
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Antony Burton
Sent: Wednesday, April 03, 2013 5:32 PM
To: CDT General developers list.
Subject: [cdt-dev] Problem Enabling/Disabling Codan
checkers programmatically (Bug?)
Hi,
We are working on a plugin
which creates a C project for ARM processors and would
like to avoid users having to delve into preferences. So
we have used the following code to modify default code
analysis preferences:
/************** enable/disable
code analysis checkers that we need or don't need...
****************************************/
IEclipsePreferences codanp =
CodanCorePlugin.getDefault().getStorePreferences();
// get pproblem
checker keys
String[] keys =
null;
try {
keys =
codanp.keys();
} catch
(org.osgi.service.prefs.BackingStoreException e) {
// TODO
Auto-generated catch block
e.printStackTrace();
}
// first disable
all problem checkers...
for (int i=0;
i<keys.length; i++) {
String res =
codanp.get(keys[i], "");
if
(!res.substring(0,1).equals("-")) {
res =
"-"+res;
}
if
(res.equals("-Error") || res.equals("-Warning") ||
res.equals("-Info")) {
codanp.put(keys[i], res);
}
}
// now enable the
checkers we need with either warning or error...
codanp.put("org.eclipse.cdt.codan.internal.checkers.SuggestedParenthesisProblem",
"Warning");
codanp.put("org.eclipse.cdt.codan.checkers.noreturn",
"Error");
codanp.put("org.eclipse.cdt.codan.checkers.errnoreturn",
"Error");
codanp.put("org.eclipse.cdt.codan.internal.checkers.SuspiciousSemicolonProblem",
"Warning");
codanp.put("org.eclipse.cdt.codan.internal.checkers.CaseBreakProblem",
"Warning");
codanp.put("org.eclipse.cdt.codan.internal.checkers.UnusedStaticFunctionProblem",
"Warning");
//...
**************************************************************************************************************************************/
This worked fine up until I
tried it in a fresh workspace, in which case the
instruction:
IEclipsePreferences codanp =
CodanCorePlugin.getDefault().getStorePreferences();
returns a value which provides
no keys.
In order to get it to work I
must go into code analysis preferences and click on the
"Apply" or "Ok" button.
Is this a bug or have I
forgotten something? Is there a work around to get it to
work in a new workspace?
Thanks in advance,
Regards,
Antony
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|