Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Problem Enabling/Disabling Codan checkers programmatically (Bug?)
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

Inactive hide details for Antony Burton ---04/08/2013 08:44:23 AM---OK will try with empty workspace. Yes, you're right, the glAntony 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

Back to the top