[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Can I change Codan defaults using my own plugin?

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
>
>