Thanks so much for reporting that.
This is a bad news.
Unfortunately, the Klocwork strategy is to not expose its reports. I think they want to privilege their internal dashboard.

With the latest version of the plugin, there is access to Klocwork Review directly within Jenkins (on the build and project page). Obviously this will not be affected by the deprecation of kwinspectreport, so the bugs/defects are still accessible from within Jenkins.

Hello again,

I have contacted Klocwork directly with regards to this to get their input on the matter. Their CTO, Gwyn Fisher, has responded with the following:

"
Whilst it may appear at first blush that Klocwork, due to deprecating kwinspectreport (note that deprecation in 9.5 means it's gone in 9.6, not 9.5 itself), is intent on steering people solely through Klocwork Review, this is not necessarily the case, although we're always happy to see people use the tools we provide (especially as Review is so 'Ooo' and 'Ahhh' these days... ;p). The old inspect reporting tool had many shortcomings from our perspective, not least of which being a login session requirement, something of a security hole in any enterprise setting. So in terms of its deprecation and replacement, the Web API (JSON over HTTP) is our interface of choice for people creating integrations such as with Jenkins or other CI frameworks. If you're concerned about the data model change from XML to JSON, and wish to keep your work in the XML domain, we have prebuilt examples that show how (in a very small number of LOC) to emit the old inspect report schema from the new API in a variety of scripting languages.
"

I hope this clarifies any concerns.

Thanks,
Jacob

Great, but CTO does not mention that web api does not provide line number for issue. And that this is by design. So that even if community creates a script to get it from web api (still don't know why this json-to-xml script cannot be provided with klocwork itself), it won't get a line number so marking source with klocwork finding will no longer be available.

Hi Krzysztof,

The response from Gwyn is as follows:

"This is indeed by design. Frankly, if you want to explore a defect, you should be doing it in the native environment, using the provided URL (from the Web API) to access Review at the right place, from where you can interact with the source, x-ref, all the nice functionality that you get there. And yes, before the question arises, reserving the line number was done specifically to avoid people trying to explore defects in environments that don't provide a rich enough infrastructure and therefore encourage developers to dismiss defects without truly understanding them (or cite them as noise, which amounts to the same thing)."

Also, when you say "marking source with Klocwork findings", what exactly do you mean? If you would like an xml/txt report with line numbers then this can be gained from Review on the "Issues" page.

Would it be possible that the plugin will still allow xml parsing for Klocwork 9.6+? But with a different schema validation?

Using http://developer.klocwork.com/community/forums/klocwork-general/web-api/webapi-issue-export-python-script with some changes we can obtain xml parseable for Jenkins and in the end have nice charts displayed in Jenkins.
However due to lack of information about faulty lines in json form webapi (no column, line, prefix, postfix, trace etc) I had to put many fake tags in the xml, to get it parsed.