I have a vague recollection that there has been a historical issue in the plugin when a shorter path is followed by a longer path in the list, and the string math falls over?

or vice versa more likely

Hmmm... can you attach the input sloccount.sc file, please? It should be present in JENKINS_HOME/jobs/YOUR_PROJECT/builds/BUILD_NUMBER/sloccount-plugin/hexNumbers_ORIGINAL_REPORT_NAME. I beware to touch this part of parsing, but it's true I didn't tested the release on Windows since I have only Linux. Is it update to 1.11 or a new plugin installation? What version of SLOCCount (not the plugin, `sloccount --version`) generated the report?

It is probably related to wrong directory separator '\' instead of '/'. Just to be sure, did you follow the specific steps for Windows described at https://wiki.jenkins-ci.org/display/JENKINS/SLOCCount+Plugin?

    private String extractFolder(String filePath){
        int index = filePath.lastIndexOf(this.fileSeparator);
        return filePath.substring(0, index); // <<<<< Line 73
    }

I will try to fix the issue tomorrow and optionally release a new version, thanks for help.

Code changed in jenkins
User: Michal Turek
Path:
src/main/java/hudson/plugins/sloccount/SloccountPublisher.java
src/main/java/hudson/plugins/sloccount/model/SloccountReport.java
src/test/java/hudson/plugins/sloccount/model/SloccountReportTest.java
http://jenkins-ci.org/commit/sloccount-plugin/2174a03468f9516f9bba9769e7e5ceaf4ea1bd41
Log:
JENKINS-21419 Can't open sloccount table portlet

• The code used System.getProperty("file.separator") for detection of unix/windows directory separator. This technique may be dangerous now, because the SLOCCount report (output from sloccount utility) may be generated on slave (unix/windows), the same file then transfered to master (windows/unix) and lazy loaded/parsed on master. So both unix and windows separators should be considered during the parsing.
• Directory separator member variables removed from SloccountReport, System.getProperty("file.separator") is no longer used, because it lost its sense and may return not suitable value.
• Method extractFolder() tests unix separator first and then the windows one. If there is no match, empty string will be returned. -1/not found returned from lastIndexOf() will never cause StringIndexOutOfBoundsException.
• Method updateRootFolderPath() updated to try unix separator first and then the windows one.
• Unit/integration tests for the changes above created.
• Tested only on Linux, I don't have Windows machine available.
• This commit is partially inspired by André Wegmüller's two years old pull request. The code is now too incompatible, sorry.
• If no file is matching the input pattern, the publisher will output a warning to the build log.

Code changed in jenkins
User: Michal Turek
Path:
src/main/java/hudson/plugins/sloccount/SloccountResult.java
src/main/java/hudson/plugins/sloccount/model/Folder.java
src/main/java/hudson/plugins/sloccount/model/SloccountReport.java
src/test/java/hudson/plugins/sloccount/model/SloccountReportTest.java
http://jenkins-ci.org/commit/sloccount-plugin/63baeefe669e13127dbb453ff5b7896690d30ccf
Log:
JENKINS-21419 Can't open sloccount table portlet

• Links to specific folders in folder details don't work.
• All Windows backslashes are now replaced by Unix slashes at the very beginning. Only unix slashes are considered in the rest of the code, which significantly simplifies it and prevents possible errors.
• SloccountReport.extractFolder() is now used in FolderFileFilter.include() to fix the same issue that was present in extractFolder().
• Constant DIRECTORY_SEPARATOR constant is used instead of hardcoded "/".

The issue should be fixed now, version 1.12 released.

will test today.

FYI this is a windows install.

A lot of the tools (build steps) are run in shell scripts, so mixing of path separators is quite likely.

Thanks for the quicker than quick turn-around!

Fix looks good!

Great