The filename is used to read the file and build a unique hash code of the surrounding 5 lines. This hash is used to see whether the warning actually has been changed. If the file could not be read, then a sequence number is used as hash (makes not much sense, but is kind of null pattern). So we need to investigate why the files could not be read. If this is OK for you then I will add some logging statement to a patched plug-in version to see why these files could not be read. (Are these files removed immediately after the build?)

The files are not removed after the build.

I wrote above that the filenames are the full path to the file in the job workspace, I think it is clearer to say that they are the full path to the file on the machine which are in the job workspace. BTW, the filenames are identical to those listed in the checkstyle-warnings.xml file which does have a significant contextHashCode value.

Please attach or send the patched plug-in.

Code changed in jenkins
User: Ulli Hafner
Path:
src/main/java/hudson/plugins/pmd/parser/PmdParser.java
http://jenkins-ci.org/commit/pmd-plugin/bc7267d5b8eae0e8d741dcbbea5571afd8e8d174
Log:
JENKINS-14509 Added debugging of exception to module name of bug.

I should mention that the same problem applies to the DRY analysis results (dry-warnings.xml), also generated by the PMD package.

Here, I can see that the problem appeared suddenly between 2 builds where nothing I can now see should have affected the results (e.g. new plugin version). In any case, this was before the upgrade to PMD 5, so that is not related.

The dry plug-in had a similar bug, this should be fixed in release 2.30.

Just another question: did the detection of new and fixed work with PMD 4.x? Or did you start to use PMD with version 5 only? Can you please also paste the XML 'file' element of the original PMD report that is right before the violation element? In my test this look like:

<pmd version="4.1" timestamp="2008-03-18T22:17:01.031">
<file name="C:\Build\Results\jobs\ADT-Base\workspace\com.avaloq.adt.ui\src\main\java\com\avaloq\adt\env\internal\ui\actions\CopyToClipboard.java">
<violation beginline="54" endline="61" begincolumn="21" endcolumn="21" rule="CollapsibleIfStatements" ruleset="Basic Rules" package="com.avaloq.adt.env.internal.ui.actions" class="CopyToClipboard" method="execute" externalInfoUrl="http://pmd.sourceforge.net/rules/basic.html#CollapsibleIfStatements" priority="3">
These nested if statements could be combined
</violation>

Maybe here is a relative path in your file...

In case it has a absolute path, can you please try to install the latest PMD CI build from
http://faktorzehn.org:8081/job/Jenkins%20Analysis%20Plug-ins%20%28Compile%29/

I added a logging statement to the 'module' property in the pmd-warnings.xml that shows the exception message.

You are right, the file element contains a relative path

<file name="com/dbconfig/app/BackupDatabase.java">

caused by using the PMD ant target parameter shortFilenames=true.

I set it to false and ran my build twice – it correctly reported no new/fixed warnings! (though it did report a new highscore of only successful builds for 33 days...)

All duplicate code warnings are reported as new and fixed though.

About PMD 4, I imagine that because of the shortFilenames parameter it also always showed each warning as new and fixed, though I don't have any previous builds to verify that on.

Thanks a lot for your help, I consider this issue closed.

I'll make sure to check how the dry plugin reports warnings once I update to 2.30.

• David

Code changed in jenkins
User: Ulli Hafner
Path:
src/main/java/hudson/plugins/pmd/parser/PmdParser.java
http://jenkins-ci.org/commit/pmd-plugin/c2d0b6ddb814a9de28f1e6f02c26c055ccd78703
Log:
Revert "JENKINS-14509 Added debugging of exception to module name of bug."

This reverts commit bc7267d5b8eae0e8d741dcbbea5571afd8e8d174.

Thanks. I'm wondering if it is possible to derive the absolute file name in your case (to prevent others to step into the same trap). During parsing the absolute path to the workspace of a project on the slave is available in my plugin, however it seems that the source path is missing between workspace path and the file name that is reported by pmd com/dbconfig/app/BackupDatabase.java.

You would need to add some hairy heuristics to get from the pmd.xml report file to the root of the relative path filename it contains.

In my case, the report file is at job-workspace/.../sub-project/build/reports/ while the source file is at job-workspace/.../sub-project/src/main/java/

Looks like the 'Warning Plugin' (https://wiki.jenkins-ci.org/display/JENKINS/Warnings+Plugin) has the same issue.