[Geoserver-devel] findbugs integrated into build

GeoServer GeoServer Developer
1

Hi all,

I have been working with David in order to integrate his work for doing static bug analysis with findbugs and have a hudson job set up that will run the findbug report nightly. All the configuration lives in a profile so there will hopefully be minimal effect on the existing build.

Here is an example of a report from hudson.

http://hudson.opengeo.org/hudson/job/geoserver-trunk-findbugs/1/findbugsResult/

The current configuration being used is not filtering out anything, naturally we will refine this as things move forward.

The job is setup to run nightly and wont send any email notifications. If people are interested in a nightly or weekly email we can set that up but i think emailing the is premature at this point, as least until we have somewhat of a refined configuration that doesn’t emit so many warnings.

If you want to run the findbugs analysis locally there is a profile called “findbugs” that will enable it. To get around issues in the findbugs plugin to run the analysis also involves specifying the path to a “filter” file which lists bug types to exclude from the analysis. There are currently two files living in src/maven/findbugs:

  1. findbugs-excludeAll.xml

Will exclude all issues, this is designed to be run locally by developers who will modify the file removing issues they want to flag. This will allow for easily isolating a particular type of issue

  1. findbugs-excludeNone.xml

Will exclude nothing, this is currently what the configuration the build server is using.

An example of running an analysis:

mvn -P findbugs -Dfindbugs.excludeFilterFile=/full/path/to/your/checkout/src/maven/findbugs/findbugs-excludeNone.xml findbugs:findbugs

The above assumes the source tree has previously been compiled, the findbugs goal won’t compile any code.

-Justin

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

2

Cool Justin, thanks for setting that up.

I added a page to the developers’ manual about using Findbugs: http://docs.geoserver.org/latest/en/developer/findbugs-guide/index.html

Regarding filters - it is nice to have a Findbugs report online, but I think that it’s important to set up email notifications to “keep us honest.” The reason I set up the excludeAll filter is to make it so that we could immediately setup email notifications without spamming the list. It’s actually a blacklist that lists each XML filter in approximate order of severity[1], so the idea would be to go down the list, removing one rule at a time, and fixing the bugs that are flagged as we go.

I think it makes more sense to have the very conservative (excludeAll) bug report on the build server (where we’re sort of imposing the check on all developers) and the looser (or even unfiltered) bug report for local runs where the developer is opting in.

[1] By “severity” here I just mean a “rank” that Findbugs assigns. I’m not sure of the math/data behind it but from my perusing the reports low ranks seem highly correlated with actual problems.

–
David Winslow
OpenGeo - http://opengeo.org/

On Tue, Mar 20, 2012 at 1:00 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,

I have been working with David in order to integrate his work for doing static bug analysis with findbugs and have a hudson job set up that will run the findbug report nightly. All the configuration lives in a profile so there will hopefully be minimal effect on the existing build.

Here is an example of a report from hudson.

http://hudson.opengeo.org/hudson/job/geoserver-trunk-findbugs/1/findbugsResult/

The current configuration being used is not filtering out anything, naturally we will refine this as things move forward.

The job is setup to run nightly and wont send any email notifications. If people are interested in a nightly or weekly email we can set that up but i think emailing the is premature at this point, as least until we have somewhat of a refined configuration that doesn’t emit so many warnings.

If you want to run the findbugs analysis locally there is a profile called “findbugs” that will enable it. To get around issues in the findbugs plugin to run the analysis also involves specifying the path to a “filter” file which lists bug types to exclude from the analysis. There are currently two files living in src/maven/findbugs:

  1. findbugs-excludeAll.xml

Will exclude all issues, this is designed to be run locally by developers who will modify the file removing issues they want to flag. This will allow for easily isolating a particular type of issue

  1. findbugs-excludeNone.xml

Will exclude nothing, this is currently what the configuration the build server is using.

An example of running an analysis:

mvn -P findbugs -Dfindbugs.excludeFilterFile=/full/path/to/your/checkout/src/maven/findbugs/findbugs-excludeNone.xml findbugs:findbugs

The above assumes the source tree has previously been compiled, the findbugs goal won’t compile any code.

-Justin

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

3

Awesome, thanks for working on this guys.

Gabriel

On Tue, Mar 20, 2012 at 2:00 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,

I have been working with David in order to integrate his work for doing
static bug analysis with findbugs and have a hudson job set up that will run
the findbug report nightly. All the configuration lives in a profile so
there will hopefully be minimal effect on the existing build.

Here is an example of a report from hudson.

http://hudson.opengeo.org/hudson/job/geoserver-trunk-findbugs/1/findbugsResult/

The current configuration being used is not filtering out anything,
naturally we will refine this as things move forward.

The job is setup to run nightly and wont send any email notifications. If
people are interested in a nightly or weekly email we can set that up but i
think emailing the is premature at this point, as least until we have
somewhat of a refined configuration that doesn't emit so many warnings.

If you want to run the findbugs analysis locally there is a profile called
"findbugs" that will enable it. To get around issues in the findbugs plugin
to run the analysis also involves specifying the path to a "filter" file
which lists bug types to exclude from the analysis. There are currently two
files living in src/maven/findbugs:

1. findbugs-excludeAll.xml

Will exclude all issues, this is designed to be run locally by developers
who will modify the file removing issues they want to flag. This will allow
for easily isolating a particular type of issue

2. findbugs-excludeNone.xml

Will exclude nothing, this is currently what the configuration the build
server is using.

An example of running an analysis:

mvn -P findbugs
-Dfindbugs.excludeFilterFile=/full/path/to/your/checkout/src/maven/findbugs/findbugs-excludeNone.xml
findbugs:findbugs

The above assumes the source tree has previously been compiled, the findbugs
goal won't compile any code.

-Justin

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

4

Hey David,

Makes sense, I have turned on email notifications running with the filterAll profile. What I would like to avoid is a situation where we disable one of the checks, resulting in failures and email, but no developer has any time to go through and squash all the issues. I guess we can cross that bridge when/if we get to it and the onus will be on the developer to commit the removed check after all the issues have been fixed.

-Justin

On Tue, Mar 20, 2012 at 1:51 PM, David Winslow <dwinslow@anonymised.com> wrote:

Cool Justin, thanks for setting that up.

I added a page to the developers’ manual about using Findbugs: http://docs.geoserver.org/latest/en/developer/findbugs-guide/index.html

Regarding filters - it is nice to have a Findbugs report online, but I think that it’s important to set up email notifications to “keep us honest.” The reason I set up the excludeAll filter is to make it so that we could immediately setup email notifications without spamming the list. It’s actually a blacklist that lists each XML filter in approximate order of severity[1], so the idea would be to go down the list, removing one rule at a time, and fixing the bugs that are flagged as we go.

I think it makes more sense to have the very conservative (excludeAll) bug report on the build server (where we’re sort of imposing the check on all developers) and the looser (or even unfiltered) bug report for local runs where the developer is opting in.

[1] By “severity” here I just mean a “rank” that Findbugs assigns. I’m not sure of the math/data behind it but from my perusing the reports low ranks seem highly correlated with actual problems.

–
David Winslow
OpenGeo - http://opengeo.org/

On Tue, Mar 20, 2012 at 1:00 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,

I have been working with David in order to integrate his work for doing static bug analysis with findbugs and have a hudson job set up that will run the findbug report nightly. All the configuration lives in a profile so there will hopefully be minimal effect on the existing build.

Here is an example of a report from hudson.

http://hudson.opengeo.org/hudson/job/geoserver-trunk-findbugs/1/findbugsResult/

The current configuration being used is not filtering out anything, naturally we will refine this as things move forward.

The job is setup to run nightly and wont send any email notifications. If people are interested in a nightly or weekly email we can set that up but i think emailing the is premature at this point, as least until we have somewhat of a refined configuration that doesn’t emit so many warnings.

If you want to run the findbugs analysis locally there is a profile called “findbugs” that will enable it. To get around issues in the findbugs plugin to run the analysis also involves specifying the path to a “filter” file which lists bug types to exclude from the analysis. There are currently two files living in src/maven/findbugs:

  1. findbugs-excludeAll.xml

Will exclude all issues, this is designed to be run locally by developers who will modify the file removing issues they want to flag. This will allow for easily isolating a particular type of issue

  1. findbugs-excludeNone.xml

Will exclude nothing, this is currently what the configuration the build server is using.

An example of running an analysis:

mvn -P findbugs -Dfindbugs.excludeFilterFile=/full/path/to/your/checkout/src/maven/findbugs/findbugs-excludeNone.xml findbugs:findbugs

The above assumes the source tree has previously been compiled, the findbugs goal won’t compile any code.

-Justin

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

5

Glad this is set up, thanks a lot Justin. I think the process you suggest for dealing with un-resolved violations makes sense too.

–
David Winslow
OpenGeo - http://opengeo.org/

On Wed, Mar 21, 2012 at 10:46 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hey David,

Makes sense, I have turned on email notifications running with the filterAll profile. What I would like to avoid is a situation where we disable one of the checks, resulting in failures and email, but no developer has any time to go through and squash all the issues. I guess we can cross that bridge when/if we get to it and the onus will be on the developer to commit the removed check after all the issues have been fixed.

-Justin

On Tue, Mar 20, 2012 at 1:51 PM, David Winslow <dwinslow@anonymised.com> wrote:

Cool Justin, thanks for setting that up.

I added a page to the developers’ manual about using Findbugs: http://docs.geoserver.org/latest/en/developer/findbugs-guide/index.html

Regarding filters - it is nice to have a Findbugs report online, but I think that it’s important to set up email notifications to “keep us honest.” The reason I set up the excludeAll filter is to make it so that we could immediately setup email notifications without spamming the list. It’s actually a blacklist that lists each XML filter in approximate order of severity[1], so the idea would be to go down the list, removing one rule at a time, and fixing the bugs that are flagged as we go.

I think it makes more sense to have the very conservative (excludeAll) bug report on the build server (where we’re sort of imposing the check on all developers) and the looser (or even unfiltered) bug report for local runs where the developer is opting in.

[1] By “severity” here I just mean a “rank” that Findbugs assigns. I’m not sure of the math/data behind it but from my perusing the reports low ranks seem highly correlated with actual problems.

–
David Winslow
OpenGeo - http://opengeo.org/

On Tue, Mar 20, 2012 at 1:00 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,

I have been working with David in order to integrate his work for doing static bug analysis with findbugs and have a hudson job set up that will run the findbug report nightly. All the configuration lives in a profile so there will hopefully be minimal effect on the existing build.

Here is an example of a report from hudson.

http://hudson.opengeo.org/hudson/job/geoserver-trunk-findbugs/1/findbugsResult/

The current configuration being used is not filtering out anything, naturally we will refine this as things move forward.

The job is setup to run nightly and wont send any email notifications. If people are interested in a nightly or weekly email we can set that up but i think emailing the is premature at this point, as least until we have somewhat of a refined configuration that doesn’t emit so many warnings.

If you want to run the findbugs analysis locally there is a profile called “findbugs” that will enable it. To get around issues in the findbugs plugin to run the analysis also involves specifying the path to a “filter” file which lists bug types to exclude from the analysis. There are currently two files living in src/maven/findbugs:

  1. findbugs-excludeAll.xml

Will exclude all issues, this is designed to be run locally by developers who will modify the file removing issues they want to flag. This will allow for easily isolating a particular type of issue

  1. findbugs-excludeNone.xml

Will exclude nothing, this is currently what the configuration the build server is using.

An example of running an analysis:

mvn -P findbugs -Dfindbugs.excludeFilterFile=/full/path/to/your/checkout/src/maven/findbugs/findbugs-excludeNone.xml findbugs:findbugs

The above assumes the source tree has previously been compiled, the findbugs goal won’t compile any code.

-Justin

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.