Findbugs plugin is missing properties that exist on findbugs ant task

Old Forum Archive
1

It’s clear that the interface to findbugs is an abstraction of the findbugs ant task, which I can see being helpful in the future where maybe the ant task isn’t being used. But in the end, it’ll always be findbugs and findbugs has certain features which are not implemented in the current plugin. Is this an oversight or just a matter of time? Either way, can a bug be created? Would a pull request be accepted that included additional attribute/elements?

The ones commonly used would be: effort, visitors, omitVisitors, excludeFilters, includeFilters, reportLevel. effort and reportLevel are essentially enums. visitors and omitVisitors are strings, and excludesFilters/includeFilters point to a single file.

From: http://findbugs.sourceforge.net/manual/anttask.html

2

You are talking about the Findbugs plugin available here:

https://github.com/ajoberstar/gradle-plugins

right? I cannot know why the author has not implemented the stuff you mention, but most likely because he has not needed it himself.

Would think you can just open a bug or create a pull request.

3

For the first version of the plugin, we tried to get the design right. More configuration options will be added in a future version. Same for all the other code quality plugins.

4

@stigkj I’m talking about the plugin that comes with gradle. The plugin you mentioned does support arbitrary arguments to findbugs (https://github.com/ajoberstar/gradle-plugins/blob/master/src/main/groovy/org/ajoberstar/gradle/findbugs/Findbugs.groovy) which get me what I’m looking for. I’m trying to stick with the gradle distribution if possible, but I might have to fallback to the one you mentioned, thanks.

@peter_niederwieser would you take pull requests that has a few more options?

5

FYI, now that the code has been contributed to Gradle, I’m not maintaining the org.ajoberstar version anymore. It hasn’t been tested since 1.0-milestone-3, so keep that in mind if you consider falling back.

I can’t speak for the Gradle devs, but in my experience they have been very receptive to pull requests.

6

Pull requests, and discussions around them, are welcome. The better the code/tests/docs, the more likely/quickly we’ll pull them.