Re: Call to action: fixing defects reported by code analysis tools

[Michael Brohl]

Avoiding duplicate errors should be managed through Jira. If someone wants to work on a class or package, he should file a Jira first so that everyone can see that this is being worked on.

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 07.07.17 um 14:14 schrieb Jacques Le Roux:

The Jenkins FindBugs plugin/publisher has a very good output with different filters and bug classification while the standard FindBugs html report is usable but far from clear. The advantage is that it is only one html file.

I agree with Michael at OFBIZ-9450 that having "the results available to the public so that the community can always access the latest bug statistics." should reduce duplicated efforts.

Jacques


Le 07/07/2017 à 12:47, Taher Alkhateeb a écrit :

If we can produce the report in HTML format, then we can create a page in wiki and include the report in this page from any URL. I guess any URL will fit, else if we need more security (should not be needed, only authenticated authors can change a wiki page) we can have it in the svn repo or a Jira link, etc.

Fantastic initiative Michael, +1

I think a simple attachment in jira or a wiki page will suffice. A
one-time scan would provide more than enough information for everyone
who needs to work on stuff. We can run it again in the future when
enough bugs have been tackled.

On Fri, Jul 7, 2017 at 1:43 PM, Michael Brohl <michael.br...@ecomify.de> wrote:

Hi everyone,

we started the first activities in Jira [1].


FindBugs code analysis after each commit


to engage contributors to work on the bugs without the need to do the
analysis themselves (quick jump in).

Are there any objections to do this?


publish results on one of our servers?

There are even projects which publish the metrics on their website [2].

Best regards,

Michael Brohl
ecomify GmbH
www.ecomify.de

[1] https://issues.apache.org/jira/browse/OFBIZ-9450

[2]

We have set up an OFBiz build on our Jenkins server who automatically does a I'm thinking about publishing the results on a web server. This should help Do we have a webspace for this which I can use or would it be appropriate to http://db.apache.org/torque/torque-3.3/releases/torque-3.3/generator/maven-reports.html

Am 29.06.17 um 12:16 schrieb Michael Brohl:

Hi all,


in helping out with this.

Every support is well appreciated, thank you!

Regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 13.12.16 um 18:35 schrieb Jacopo Cappellato:

just wanted to bring this back in mind in case there are people interested

Hi all,

thanks to Gradle we have now an easy way to run source code analysis
tools
on our codebase.

to
code that may need to be improved or fixed.

fixed.


fix
as many defects as possible: it may lead to a cleaner codebase, may

some insight on our code quality, and may make it easier for new
contributors to help the project.

So here are the steps to quickly start the process:

1) get a clean checkout of the trunk

svn co http://svn.apache.org/repos/asf/ofbiz/trunk

2) edit the build.gradle file to enable the PMD or FindBugs plugins.
For PMD you can add the following line to the file, after the other
"apply
plugin" commands:

apply plugin: 'pmd'

For FindBugs add the following lines:

apply plugin: 'findbugs'
tasks.withType(FindBugs) {
      reports {
          xml.enabled false
          html.enabled true
      }
}

Apply only pmd or findbugs, not both: the two tools provide different

in most cases, so please choose the tool of your preference and then
start
fixing the code.

3) run the analysis with the command:
./gradlew check

4) review the report;
for PMD the report is:
build/reports/pmd/main.html
for FindBugs the report is:
build/reports/findbugs/main.html

5) fix some bugs and test; then go back to #3


reported by PMD/FindBugs

Feel free to ask here any question!

Jacopo

Tools like PMD and FindBugs generate useful reports containing pointers In fact I have executed them on trunk and I got reports with thousands of "rule violations": some of them are probably false positives but others really represent code that can be improved, simplified or, in some cases, I think that it would be great if this community will work together to increase the confidence of potential adopters that use these tools to get analysis with plenty of defects but the two tools will spot the same ones 6) create a patch and submit it to Jira, mentioning that it fixes defects

smime.p7s
Description: S/MIME Cryptographic Signature