Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-13411

Klocwork XML output is deprecated

    Details

    • Similar Issues:

      Description

      As http://www.klocwork.com/products/documentation/current/Kwinspectreport states: XML report is deprecated in KW 9.5 and will no longer be available. I recommend that plugin uses some other parser for the issues (csv maybe) or use web api to get the issues.

        Attachments

          Activity

          Hide
          gbois Gregory Boissinot added a comment -

          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.

          Show
          gbois Gregory Boissinot added a comment - 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.
          Hide
          jacoblarfors Jacob Larfors added a comment -

          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.

          Show
          jacoblarfors Jacob Larfors added a comment - 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.
          Hide
          jacoblarfors Jacob Larfors added a comment -

          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

          Show
          jacoblarfors Jacob Larfors added a comment - 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
          Hide
          raspy Krzysztof Malinowski added a comment -

          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.

          Show
          raspy Krzysztof Malinowski added a comment - 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.
          Hide
          jacoblarfors Jacob Larfors added a comment -

          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.

          Show
          jacoblarfors Jacob Larfors added a comment - 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.
          Hide
          carno M S added a comment -

          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.

          Show
          carno M S added a comment - 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.

            People

            • Assignee:
              gbois Gregory Boissinot
              Reporter:
              raspy Krzysztof Malinowski
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: