One more issue in making the Hudson to Jenkins switch...

The Hudson/Jenkins continuous integration server relies on using Jelly scripts, which is considered some type of executable XML format. The format resembles sort of like Django/Jinja2 templates with very little documentation to accompany how it all works. Hudson/Jenkins documents have very few references, so you're left to guess what the statements such as the index.jelly in the Violations plug-in actually do.

One issue encountered was using the Violations plug-in, which allows users to see exactly which lines of code triggered Pylint, PEP8, JSLint-releated errors. The Violations plug-in parses the error codes from these files and supposedly renders the summary similar to how its shown below (taken from https://wiki.jenkins-ci.org/download/attachments/2916418/violations-file-1.png?version=1&modificationDate=1187153094000):

The problem in Jenkins was that the screen above was blank, whereas Hudson didn't have this issue. While tracing through the code, it also didn't seem like there were that many drastic changes with this plugin over the past 4-5 years. Reverting back to a previously known working version of the Violations plugin on Hudson also showed the same phenomenon on Jenkins.

Furthermore, it turns out this particular section in the Violations plug-in seems to have problems. The template attempts to set a variable named 'model' using the {it.fileModel} attribute, which corresponds to a getFileModel() function within the code. There is also a getDisplayName() function inherited from the AbstractFileModel.java, which is inherited by FileModel.java.

   <l:main-panel>
<j:set var="model" value="${it.fileModel}"/>

<j:set
var="image"
value="${rootURL}/plugin/violations/images/48x48/dialog-warning.png"/>

<j:set
var="iconDir"
value="${rootURL}/plugin/violations/images/16x16"/>

<j:set var="href" value="${it.showLines}"/>
<h3><img src="${image}"/> ${model.displayName}</h3>


<j:forEach var="t" items="${model.typeMap.entrySet()}">
<table class="pane">
 <tbody>
   <tr><td class="pane-header" colspan="5">${it.typeLine(t.key)}</td></tr>
   <j:forEach var="v" items="${t.value}">
     <tr>
       <td class="pane">
         <j:if test="${href}">
           <a href="#line${v.line}">${v.line}</a>
         </j:if>
         <j:if test="${!href}">
           ${v.line}
         </j:if>
       </td>
       <!--<td class="pane">${v.source}</td> -->
       <td class="pane">${it.severityColumn(v)}</td>
       <td class="pane" width="99%">${v.message}</td>
     </tr>
   </j:forEach>
 </tbody>
</table>
<p></p>
</j:forEach>

The issue was first reported last month in this ticket. The problem didn't appear in any Hudson-based servers, so the problem appears to have occurred when making the switch from Hudson to Jenkins. The workaround to resolve the issue was to create the two functions within FileModel.java, as shown in this pull request.

   /**
 * Get the display name of this file.
 * @return the name to use whrn displaying the file violations.
 */
@Override
    public String getDisplayName() {
    return super.getDisplayName();
}

/**
 * Get the map of types to violations.
 * @return the type to violation map.
 */
@Override
    public TreeMap> getTypeMap() {
    return super.getTypeMap();
}

It's not clear to me why one needs to expose the methods and call a subclasses' parent methods, but all of a sudden, the Violations summary screen came to life after making this fix and recompiling the plugin. Although this Violations plugin hasn't been updated in the recent 8 months, one can only hope that Jenkins users will make sure to merge the fix and re-release the binary soon!