|
Define tool component object to represent tool driver and its extensions/plugins?
EBALLOT PROPOSAL: define a mechanism to allow a tool to explicitly detail any plug-ins or extensions that were in play during the analysis run (and which potentially contribute to changes in analysis behavior).
API IMPACT
tool.sarifLoggerVersion property deleted (as it hasn't been helpful to date)
Define a toolComponent object to represent a tool's driver and its extensions.
Transfer all existing tool properties except language to toolComponent, with the following changes:.
Change the type of the shortDescription property from message object to multiformatMessageString object.
Change the type of the fullDescription property from message object to multiformatMessageString object.
Add a property artifactIndex to locate the component in the run.artifacts array.
In the tool object:
Add a property driver of type toolComponent to represent the driver: required
Add a property extensions of type array of toolComponent to represent all extensions.
Add toolComponent as a new file role.
NOTES
Since conversion.tool was and remains a tool instance, a converter has a driver and can have extensions.
result.rulePointer can be used to associate a result with an extension (see #324 for more)
https://github.com/oasis-tcs/sarif-spec/issues/179
|
