Various smaller issues with output

[TheRealAgentK]

1. If -verbose is off, CFLint XML should not be output to the console after processing.
2. CFLint XML should not be output to the console once per output type, i.e. I output XML and HTML and it dumps the underlying XML to the console twice.
3. CFLint/CFParser tokens are currently output in dev during parsing. That's probably useful info, but only in verbose mode.
4. JSON and TEXT output don't include the number of files checked and the number of LOC checked information as XML does.

[ryaneberly]

All except 4 are taken care of. Good catch

[TheRealAgentK]

Cool, will give it a quick test and then then fix number 4 from the list, too.

[TheRealAgentK]

I fixed number 4.

There's an issue in TestFiles though. In JSON, totalfiles and totalsize will always be 0 each. That is because those values get incremented in CFLint.scan(...) which doesn't seem to be used in the TestFiles setup. I'd be happy to accept that those tests will always report 0/0.

I regenerated all the expected test files, and then realised that it has changed the file paths too:

-    "file" : "src\\test\\resources\\com\\cflint\\tests\\BuiltInFunctionChecker\\isDate2.cfm",
+    "file" : "src/test/resources/com/cflint/tests/BuiltInFunctionChecker/isDate2.cfm",

I'm pretty sure that should work across Win/Mac/Linux, but it'd be good if you could test that @ryaneberly .

[ryaneberly]

Yes, the expected file is representative of the system it was generated on, but the tests will pass regardless of the system.

…

On Sun, Jul 2, 2017 at 12:16 AM, Kai Koenig ***@***.***> wrote: Closed #323 <#323>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#323 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFtZu8yDdp4oErE5kfE3f_m_phuvRJDhks5sJxmRgaJpZM4OLNY4> .

[ryaneberly]

I agree with @KamasamaK's comment on #331.

The original JSON format is:
[ {"severity" : "INFO", ...} ]

The current format in dev is:

[ {"severity" : "INFO", ...}, {
  "totalfiles" : 3
}, {
  "totalsize" : 18
}, {
  "code" : "COMPONENT_INVALID_NAME",
  "count" : 1
}, {
  "severity" : "INFO",
  "count" : 1
} ]

I think we need to redefine it as:

{ "issues": [ {"severity" : "INFO", ...} ],
  "summary": {
  "totalfiles" : 3,
  "totalsize" : 18,
  "countByCode" : [
 {
  "code" : "COMPONENT_INVALID_NAME",
  "count" : 1
}],
 "countBySeverity": [ {
  "severity" : "INFO",
  "count" : 1
}]
}

[KamasamaK]

@ryaneberly I agree with your proposed format. That organization makes much more sense. It's technically a bigger change, but will be easier to re-integrate as will be likely since both changes are breaking. 😀

[TheRealAgentK]

Yes, I agree with that too, much better format - I'll change it tomorrow.

[TheRealAgentK]

Note to self: Change user manual after this change.

[TheRealAgentK]

I think format is fine now - need someone to have a quick look at three of the tests that behave weird. Let me know what you think, if it's all ok I'll change the user guide.

[ryaneberly]

@TheRealAgentK, Thanks. I'll look tonight

[KamasamaK]

The structure looks good now. A few comments about the format:

1. Perhaps we could rename totalsize as totalLines to be more clear on the meaning.
2. If we are using a camelCase convention, which it seems we are based on other names, then totalfiles should be totalFiles.
3. The summary object lacks consistent naming with the counts element in the XML format.
4. Now that it's an object, I think we can safely add some missing XML attributes -- notably, version and timestamp:

{
  "version": "1.2.0",
  "timestamp": "1501170620",
  "issues": [ {"severity" : "INFO", ...}, ... ],
  "summary": { ... }
}

[TheRealAgentK]

1/2 - Happy to do that, will name them totalLines and totalFiles in JSON and XML and internally
3 - I won't touch that because counts already existed in CFLint XML since Feb 2016 and I don't want to break existing format in 1.2 - that might happen in 2.0 though
4 - Yes, good call - will do that too.

[KamasamaK]

@TheRealAgentK Regarding 3, it's up to you guys which name you prefer. Since summary is new to the JSON format as far as I can tell, you could make them consistent by having the JSON use counts instead. I have no strong opinion on which name to use. As for breaking the format, that's already done with the JSON so why stop there? 😄

[ryaneberly]

@KamasamaK
That's fair, but we should still minimize the collateral

[TheRealAgentK]

That's actually a good point.

[TheRealAgentK]

If @KamasamaK doesn't mind I'll rename summary to counts in JSON, then at least XML doesn't break and it's consistent for now.