Re: [cdt-dev] Can I change Codan defaults using my own plugin?

[Alena Laskavaia <elaskavaia.cdt@xxxxxxxxx>]

This is not implemented, but ideally you can manage profiles
independently and store them where you like.
There is no default profile now as file - it is generated from
extension points and defaults params are hardcoded (ugly but I did not
have time to fix it). So the only way now - it to change extension
points with different defaults and re-deploy plugins.

On Wed, Apr 6, 2011 at 3:31 PM, Andrew Gvozdev <angvoz.dev@xxxxxxxxx> wrote:
> This is actually interesting question. How would one to change default Codan
> settings for the whole team? In our case we provide a specialized plugin, is
> it possible to "fix" Codan defaults (and a few other preferences for that
> matter) according to company-wide policy using that plugin?
> Andrew
>
>>
>> Le 6 avr. 2011 à 21:09, Pox Pox <ax2rou@xxxxxxxxxx@hotmail.fr> a écrit :
>>
>> > And what if (and it is often the case) the people that hides the problem
>> > is not the only one to work on the file? Hidden problems need to be
>> > physically saved and shared to the whole dev team
>> >
>> > Maxime
>> >
>> >
>> > Le 6 avr. 2011 à 17:40, Alena Laskavaia <elaskavaia.cdt@xxxxxxxxx> a
>> > écrit :
>> >
>> >> For custom checker you have to create a custom parameter to hide it.
>> >> For example Statement has no effect checker uses argument of problem
>> >> to hide them. Fall through break uses lines comments to suppress
>> >> specific onces. Never use line number for his - it won't work because
>> >> it always changes.
>> >>
>> >> On Wed, Apr 6, 2011 at 11:02 AM, Maxime Dechatre
>> >> <maximed@xxxxxxxxxxxxxxxxxxx> wrote:
>> >>> Chekers I created myself, all extending AbstractIndexAStChecker.
>> >>> The fact is that they check validity of rules established by my
>> >>> company's standards. If this rules arent respected, a violation can be
>> >>> justified. So I need to at least hide a warning, for a given checker, in a
>> >>> given file, for a given node.
>> >>>
>> >>> Maxime
>> >>>
>> >>>
>> >>> Le 6 avr. 2011 à 16:57, Alena Laskavaia <elaskavaia.cdt@xxxxxxxxx> a
>> >>> écrit :
>> >>>
>> >>>> What checker? Some checkers do support comment suppression and other
>> >>>> ways of suppression
>> >>>>
>> >>>> On Wed, Apr 6, 2011 at 2:57 AM,  <maximed@xxxxxxxxxxxxxxxxxxx> wrote:
>> >>>>> Ok, now I see. Indeed it is just as what the other person needed and
>> >>>>> what I
>> >>>>> thought I needed. But my boss wants  to exclude one given reported
>> >>>>> problem
>> >>>>> in one line, and let the other one be dispalyed.
>> >>>>> Alena Laskavaia <elaskavaia.cdt@xxxxxxxxx> a écrit :
>> >>>>>
>> >>>>>> No - in CDT 8. Obviously I am not adding new features to CDT 7.
>> >>>>>>
>> >>>>>> On Mon, Apr 4, 2011 at 2:27 PM, Maxime Dechatre
>> >>>>>> <maximed@xxxxxxxxxxxxxxxxxxx> wrote:
>> >>>>>>>
>> >>>>>>> On helios 3.6.2 with CDT 7?
>> >>>>>>>
>> >>>>>>> Maxime
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Le 4 avr. 2011 à 15:42, Alena Laskavaia <elaskavaia.cdt@xxxxxxxxx>
>> >>>>>>> a
>> >>>>>>> écrit :
>> >>>>>>>
>> >>>>>>>> I just explain it is all implemented already. Juts turn off the
>> >>>>>>>> checkers in preferences and for each checker there is filter for
>> >>>>>>>> files!
>> >>>>>>>>
>> >>>>>>>> On Mon, Apr 4, 2011 at 8:33 AM,  <maximed@xxxxxxxxxxxxxxxxxxx>
>> >>>>>>>> wrote:
>> >>>>>>>>>
>> >>>>>>>>> Hi.
>> >>>>>>>>> Got a solution here. I don't have performance problems, but my
>> >>>>>>>>> problem
>> >>>>>>>>> is
>> >>>>>>>>> near yours: the more errors there are, the less it is usefull.
>> >>>>>>>>> Our ideas here:
>> >>>>>>>>>   1/ Insert a #pragma in the file for each checker you don't
>> >>>>>>>>> want to
>> >>>>>>>>> use
>> >>>>>>>>>   2/ Put the same type of information in comments.
>> >>>>>>>>> I know, the problem is that it changes the code (which is no
>> >>>>>>>>> loger
>> >>>>>>>>> valid in
>> >>>>>>>>> my case).
>> >>>>>>>>>
>> >>>>>>>>> So:
>> >>>>>>>>>   3/ Define a XML which specifies, for each file you don't want
>> >>>>>>>>> to use
>> >>>>>>>>> all
>> >>>>>>>>> checkers on, which checker you wanna disable. Then, when
>> >>>>>>>>> launching
>> >>>>>>>>> checker,
>> >>>>>>>>> insert a XML files reader that computes all you need.
>> >>>>>>>>>
>> >>>>>>>>> I'm interrested in your needs and remarks, tell me if it sounds
>> >>>>>>>>> a good
>> >>>>>>>>> idea
>> >>>>>>>>> for you.
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> Jesper Eskilson <jesper.eskilson@xxxxxxx> a écrit :
>> >>>>>>>>>
>> >>>>>>>>>> On 03/31/2011 10:13 PM, Alena Laskavaia wrote:
>> >>>>>>>>>>>
>> >>>>>>>>>>> It is all implemented already.
>> >>>>>>>>>>> Disable the errors you don't want. Note is you see lots of
>> >>>>>>>>>>> false
>> >>>>>>>>>>> positives your indexer is not set up correctly and it will
>> >>>>>>>>>>> report
>> >>>>>>>>>>> garbage mostly anyway.
>> >>>>>>>>>>> You can turn on/off folders/files in preferences for problems
>> >>>>>>>>>>> (in cdt
>> >>>>>>>>>>> 8.0). Select bunch of errors you want to apply it too and
>> >>>>>>>>>>> click
>> >>>>>>>>>>> Customize...
>> >>>>>>>>>>
>> >>>>>>>>>> I'm still trying to get the scoping rules right, the problem is
>> >>>>>>>>>> that
>> >>>>>>>>>> each
>> >>>>>>>>>> time I try to change something, Codan blocks Eclipse for at
>> >>>>>>>>>> least 30
>> >>>>>>>>>> minutes. Maybe I should disabled all checkers except one and
>> >>>>>>>>>> get the
>> >>>>>>>>>> filters
>> >>>>>>>>>> right, and then add some more checkers.
>> >>>>>>>>>>
>> >>>>>>>>>> Maybe it would make sense for Codan to try to limit itself when
>> >>>>>>>>>> it
>> >>>>>>>>>> realizes that it is taking lots of time/resources (reporting
>> >>>>>>>>>> 50000
>> >>>>>>>>>> errors
>> >>>>>>>>>> doesn't make sense anyway). Completely blocking Eclipse for 30
>> >>>>>>>>>> minutes
>> >>>>>>>>>> is
>> >>>>>>>>>> unacceptable, even if it is possible to limit the scope and the
>> >>>>>>>>>> number
>> >>>>>>>>>> of
>> >>>>>>>>>> checkers. Users won't know that they need to do that until they
>> >>>>>>>>>> are
>> >>>>>>>>>> sitting
>> >>>>>>>>>> there with a Eclipse which is blocked by a long-running
>> >>>>>>>>>> analysis, and
>> >>>>>>>>>> by
>> >>>>>>>>>> then it is too late.
>> >>>>>>>>>>
>> >>>>>>>>>> --
>> >>>>>>>>>> Jesper Eskilson, Developer
>> >>>>>>>>>> IAR Systems AB
>> >>>>>>>>>> Box 23051, Strandbodgatan 1
>> >>>>>>>>>> SE-750 23 Uppsala, SWEDEN
>> >>>>>>>>>> Phone: +46 18 16 78 00 Fax: +46 18 16 78 38
>> >>>>>>>>>> E-mail: jesper.eskilson@xxxxxxx Website: www.iar.com
>> >>>>>>>>>> Twitter: www.twitter.com/iarsystems
>> >>>>>>>>>>
>> >>>>>>>>>> _______________________________________________
>> >>>>>>>>>> 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
>
>