Findbugs 2.4 includes the fbcontrib package. Did you try that version?

Do you need other (or own) plugins to be integrated with the plugin?

Ah, I hadn't noticed the latest release. It works with 2.4. I don't have any
other plugins that I use but this may be a useful enhancement for others if they
have their own plugins.

Fixed in 2.4.

If there is a requirement for someone to use plug-in messages of a self written
plug-in, please re-open.

In our projects the client is not allowed to use his own time. Instead it has to get the Servertime.

We've created our own Findbugs-Rules for the use of e.g. new Date().
The Findbugs-Plugin is set to fail the build as soon as a High-Priority-Bug is reported.

The plugin is capable of reading our resulting findbugs.xml just fine but since it doesn't recognize the "bug" it's considered "experimental" with a "low priority" which is not failing the build.

We've added our .jar to the "plugins/findbugs/WEB-INF/lib"-folder and editet the bugrank.txt, findbugs.xml and messages.xml in the library-2.0.0-hudson3a.jar.
This is working for us but we have to redo this every time we update the plugin (at least that's what I believe. We configured this just now and of course updated everything before we did so).

An easier way for us to reference external Rules would be appreciated.

I think these are actually two points:

1) Show the correct priority
2) Show the messages of additional rules

Shouldn't 1) be automatically resolved by the finddbugs library? Is the actual bug rank not part of the created findbugs.xml file? Or is the rank just part of the rules jar?

Sorry for the late reply,
I expected an email if there would occur any changes to this thread and since I got none I just saw your reply this morning.

For our findbugs-run we are using a locally installed version of findbugs with our added rules.
The resulting findbugs.xml contains the following BugInstance and BugPattern:
<BugInstance type="TS_JAVA_UTIL_DATE_CTOR" priority="1" abbrev="TS" category="CORRECTNESS" instanceHash="d3576a048cadb3be35d6c865f2150532" instanceOccurrenceNum="0" instanceOccurrenceMax="0">
<BugPattern type="TS_JAVA_UTIL_DATE_CTOR" abbrev="TS" category="CORRECTNESS">

When using the plugin we thought that you would only parse the xml-file without the need of findbugs itself but that's obviously wrong.
Reading about the "BugRank"-Concept introduced in Release 4.13 we tried just adding our entry to the bugrank.txt but that wasn't helping either.

To make it easier for you to get at our problem I've performed a series of tests.
The 4 relevant files are:

1. bugrank.txt
2. findbugs.xml
3. messages.xml
4. our jar

During my tests I've added the files one by one to the library-2.0.0-hudson3a.jar found in the lib-folder of the plugin respectively our jar directly to that folder.
As long as the findbugs.xml is missing the System considers the above BugInstance as "Low Priority" within the "Experimental"-Category.
When inserting our bug-descriptions into the findbugs.xml the PluginLoader tries to instantiate the class resulting in:

> Caused by: edu.umd.cs.findbugs.PluginException: Could not instantiate detector class: java.lang.ClassNotFoundException: de.findbugs.detector.TimeServiceDetector
> at edu.umd.cs.findbugs.PluginLoader.init(PluginLoader.java:638)
> at edu.umd.cs.findbugs.PluginLoader.loadPlugin(PluginLoader.java:254)
> at edu.umd.cs.findbugs.PluginLoader.loadInitialPlugins(PluginLoader.java:1053)
> ... 23 more
> Caused by: java.lang.ClassNotFoundException: de.findbugs.detector.TimeServiceDetector
> at java.net.URLClassLoader$1.run(URLClassLoader.java:200)

Adding our jar to the libs-folder of the plugin it is missing the detector description:

> Caused by: edu.umd.cs.findbugs.PluginException: Missing Detector description for detector de.findbugs.detector.TimeServiceDetector
> at edu.umd.cs.findbugs.PluginLoader.findMessageNode(PluginLoader.java:907)
> at edu.umd.cs.findbugs.PluginLoader.init(PluginLoader.java:625)
> at edu.umd.cs.findbugs.PluginLoader.loadPlugin(PluginLoader.java:254)
> at edu.umd.cs.findbugs.PluginLoader.loadInitialPlugins(PluginLoader.java:1053)

Adding the messages.xml the System suddenly considers the BugInstance as "Normal Priority" whithin the choosen "Correctness"-Category.
So we are nearly there, the only thing not working out is the priority. Adding the our information to the bugrank.txt resolves the last issue.

The StackTraces are way longer if you need more of it feel free to ask.

One minor issue remains. The BugPattern in the findbugs.xml lists as follows:
<BugPattern type="TS_JAVA_UTIL_DATE_CTOR" abbrev="TS" category="CORRECTNESS">
<ShortDescription>Direkter Zugriff auf new java.util.Date()</ShortDescription>
<Details><![CDATA[

<p>Long German Text</p>
<p>LGT Part 2</p>

]]></Details>
</BugPattern>

The Results Page is missing the Details:
> Zugriff auf new java.util.Date() ohne den TimeService gefunden in de.psi.passage3.kernel.test.gui.filter.AbstractTestFilterPanelVC$1.run().0 comments
>
> Keine Beschreibung vorhanden.

I hope this helps you with our problem if I'm missing a majof point of plugin-installation, classpath etc. just tell me.

BTW: Thanks a lot for your great plugins!

Ok, now I understand. What basically is missing is a way to upload (or configure) additional findbugs plug-ins. This will be quite complicated since Hudson may run in an application server and the classloading needs to be carefully done.

One side note: since normally the findbugs.xml file contains only the warnings short message (and not the long one) the plug-in loads the bundles messages.xml files. This is the reason for the last problem in your description. I.e., this file needs to be added (resolved), too.

Custom FindBugs detectors are awesome! I wish Jenkins would display their details and categories correctly.

It would be most convenient if one could configure the custom detectors from the Jenkins console, the way one adds detectors in Eclipse.

Note that generating the xml output with option "xml:withMessages" helps. That way, at least, the short description is included. (Perhaps FindBugs should provide more of these options, e.g., withDetails, etc.?)

I think as a first step we should analyze how we can dynamically load the classes of an external jar file in a Jenkins plug-in. I'm not sure how easy this would be...

FindBugs Plugins placed in ~<jenkins-user-home>/.findbugs/plugin are loaded by all FindBugs instances, including (this) Jenkins FindBugs Plugin.

Nevertheless, I still promote finding a solution for having a "plugin" folder for FindBugs plugins to be loaded by the Jenkins FindBugs plugin.

Maybe -Dfindbugs.home=XXX also plays a role here...

Did you check this in a master slave setup? What do you think would be the best way to provide that feature? Provide the possibility to upload and manage a list of plug-ins?

I have only tested this in a master only setup and have no means to test a master/slave setup currently.
The best way to provide this feature IMHO would be to use the means envisaged by a regular (stand-alone) FindBugs Setup. As I am not quite certain how your Plugin loads FindBugs, I can only guess what could work. Setting certain Java System Properties or calling the according setters on the FindBugs API could help "expose" a folder to FindBugs where it would look for plugins or provide a list of such. A stand-alone FindBugs looks in <findbugs.home>/plugin.
lbrinkmann suggested that plugins (packaged as jars) get loaded if placed in the lib-folder of the Jenkins plugin. Properly packaged plugins provide their findbugs.xml, messages.xml and BugRank.txt in the jar.

i'm willing to help in testing this, i'm looking into running security analysis using findbugs plugin http://h3xstream.github.com/find-sec-bugs/.
so it's be great to see findbugs show security category as well.

@Eyal: Adding an open source findbugs library would be much easier to implement: just create a new issue then I will add the messages files of that library to the parser... The upload feature is only required for closed source findbugs plugins...

@Ulli: Like @Eyal I would also like to use the find-sec-bugs plugin and have the results reported by the Jenkins plugin. I'm using the Ant findbugs task to generate my findbugs XML result file and have the latest version 4.48 of the plugin.

The find-sec-bugs bug types and detailed messages are showing correctly, but all of the bug types are classified under the EXPERIMENTAL category - even though in the findbugs.xml results file they are classified correctly under the SECURITY category.

We want to highlight security bugs to our developers, but if we can't classify them under SECURITY in Jenkins the find-sec-bugs analyzers are pretty much useless. Is there a workaround or fix for this ?

@jesseglick: Thanks a bundle !

We could really benefit from being able to use our own findbugs plugin with Jenkins plugin. Maybe FindBugsMessages could load message xml files following *message.xml pattern?

Pull #3 was merged in 4.49. Does it resolve this issue generally or just one case?

Is this still required?

In addition to the comment of Piotr,

we would also benefit when the messages of our own findbugs detectors are known and thus shown in Jenkins.

Ok, then I reopen and rephrase this issue since this feature might help other tools as well.

Is there any change this issue is picked up for one of the coming releases?

I do not have capacity to work on that issue. Maybe someone of the watchers can help here?

As a workaround, one can implement a simple and almost empty Jenkins plugin that provides a new ReportScanning descriptor that overrides the getDescription method. Are your messages in the FindBugs XML format?