Re: Filtering out (some) Sonar violations
great news!!! have a nice WE, all the best!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ 2011/8/5 Francesco Chicchiriccò ilgro...@apache.org: Hi folks, short time after asking [1], people at infrastructure made a custom ruleset for Cocoon at Sonar [2] and we have no more Blocker or Critical violations. Kudos to the infrastructure team! [1] https://issues.apache.org/jira/browse/INFRA-3828 [2] https://analysis.apache.org/rules_configuration/index/10 On 05/08/2011 11:57, Steven Dolg wrote: Am 05.08.2011 11:25, schrieb Nathaniel, Alfred: Hi Francesco, I am a big fan of Findbugs and persueing a zero-warnings policy. In other projects we use a Findbugs exclude filter file to disable warnings and document the deliberation for doing so. That's what we do as well. TBH, the default ruleset contains more than one rule that I find highly suspicious if not outright stupid. Zero warnings is IMO the only way to go, same as with unit tests. Sonar should foresee to pull such an exclude filter from the project's code base. NB we also exclude XFB_XML_FACTORY_BYPASS with reason axis.client.Stub requires specific axis.message.SOAPHeaderElement. Maybe we should try to get our own set of rules (there are rulesets CXF Rules with Findbugs and My Faces with Findbugs, so I guess that's possible). I think it's easier to start with a more lenient ruleset, work (close) to 0 warnings and then add a couple more restrictions and repeat. Sitting in front of hundreds of warnings can be a frustrating situation... Steven Cheers, Alfred. -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Freitag, 5. August 2011 08:50 To: dev@cocoon.apache.org Subject: Filtering out (some) Sonar violations ... My proposal would be to open a issue to INFRA in order to ask for disabling these two rules: do you see any problem, with this? For my personal experience about Findbugs, PMD and Checkstyle, it is rather impossible to satisfy all the rules (thus bringing the number of violations to zero); however, I personally think that reducing the huge amount that we have at the moment would dramatically improve Cocoon 3's source code quality. ... The content of this e-mail is intended only for the confidential use of the person addressed. If you are not the intended recipient, please notify the sender and delete this e-mail immediately. Thank you. -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/
Re: Filtering out (some) Sonar violations
Am 05.08.2011 11:25, schrieb Nathaniel, Alfred: Hi Francesco, I am a big fan of Findbugs and persueing a zero-warnings policy. In other projects we use a Findbugs exclude filter file to disable warnings and document the deliberation for doing so. That's what we do as well. TBH, the default ruleset contains more than one rule that I find highly suspicious if not outright stupid. Zero warnings is IMO the only way to go, same as with unit tests. Sonar should foresee to pull such an exclude filter from the project's code base. NB we also exclude XFB_XML_FACTORY_BYPASS with reason axis.client.Stub requires specific axis.message.SOAPHeaderElement. Maybe we should try to get our own set of rules (there are rulesets CXF Rules with Findbugs and My Faces with Findbugs, so I guess that's possible). I think it's easier to start with a more lenient ruleset, work (close) to 0 warnings and then add a couple more restrictions and repeat. Sitting in front of hundreds of warnings can be a frustrating situation... Steven Cheers, Alfred. -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Freitag, 5. August 2011 08:50 To: dev@cocoon.apache.org Subject: Filtering out (some) Sonar violations ... My proposal would be to open a issue to INFRA in order to ask for disabling these two rules: do you see any problem, with this? For my personal experience about Findbugs, PMD and Checkstyle, it is rather impossible to satisfy all the rules (thus bringing the number of violations to zero); however, I personally think that reducing the huge amount that we have at the moment would dramatically improve Cocoon 3's source code quality. ... The content of this e-mail is intended only for the confidential use of the person addressed. If you are not the intended recipient, please notify the sender and delete this e-mail immediately. Thank you.
Re: Filtering out (some) Sonar violations
Hi folks, short time after asking [1], people at infrastructure made a custom ruleset for Cocoon at Sonar [2] and we have no more Blocker or Critical violations. Kudos to the infrastructure team! [1] https://issues.apache.org/jira/browse/INFRA-3828 [2] https://analysis.apache.org/rules_configuration/index/10 On 05/08/2011 11:57, Steven Dolg wrote: Am 05.08.2011 11:25, schrieb Nathaniel, Alfred: Hi Francesco, I am a big fan of Findbugs and persueing a zero-warnings policy. In other projects we use a Findbugs exclude filter file to disable warnings and document the deliberation for doing so. That's what we do as well. TBH, the default ruleset contains more than one rule that I find highly suspicious if not outright stupid. Zero warnings is IMO the only way to go, same as with unit tests. Sonar should foresee to pull such an exclude filter from the project's code base. NB we also exclude XFB_XML_FACTORY_BYPASS with reason axis.client.Stub requires specific axis.message.SOAPHeaderElement. Maybe we should try to get our own set of rules (there are rulesets CXF Rules with Findbugs and My Faces with Findbugs, so I guess that's possible). I think it's easier to start with a more lenient ruleset, work (close) to 0 warnings and then add a couple more restrictions and repeat. Sitting in front of hundreds of warnings can be a frustrating situation... Steven Cheers, Alfred. -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Freitag, 5. August 2011 08:50 To: dev@cocoon.apache.org Subject: Filtering out (some) Sonar violations ... My proposal would be to open a issue to INFRA in order to ask for disabling these two rules: do you see any problem, with this? For my personal experience about Findbugs, PMD and Checkstyle, it is rather impossible to satisfy all the rules (thus bringing the number of violations to zero); however, I personally think that reducing the huge amount that we have at the moment would dramatically improve Cocoon 3's source code quality. ... The content of this e-mail is intended only for the confidential use of the person addressed. If you are not the intended recipient, please notify the sender and delete this e-mail immediately. Thank you. -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/
