This section describes the additional configurations you can apply to the Multi-Language Pack. In this section:
Third-party Analyzer Rule Documentation
When an analyzer extension sends results to DTP, you will be able to view violations from the DTP web application, as well as in your IDE (e.g., Eclipse, Visual Studio, etc.). DTP can also display the third-party documentation for individual rules, making it easier to understand the violations. Once the rule documentation is installed in DTP, it will be accessible in DTP and your IDE.
- Download the extension distribution on the machine running DTP.
- Copy the <ANALYZER_HOME>/rulesdoc/<analyzer_name> directory to the <DTP_HOME>/tomcat/webapps/grs/rulesdoc directory.
- Restart DTP Services (see Stopping DTP Services and Starting DTP Services).
The rule documentation will be available in DTP's Violation Explorer, as well as when results are reviewed in a supported IDE.
Back up rules when upgrading DTP
The <DTP_HOME>/tomcat/webapps/grs/rulesdoc directory is removed when DTP is upgraded. Be sure to recopy the entire contents of the <ANALYZER_HOME>/ruledoc directory back to the <DTP_HOME>/tomcat/webapps/grs/ruledoc directory after upgrading DTP.
Advanced Configuration
You can customize the details and metadata associated with the code analysis rules. This enables you to implement a code analysis policy that meets your organization's specific needs. The configurations detailed in this section are typically performed by your Parasoft representative.
Customizing Rule Details and Metadata
Parasoft DTP displays code analysis violations according to severity level, rule category, and other characteristics according to a rule map XML file. You can edit the rule map to change the default rule settings, as well determine how new rules that are not yet defined in the rule map are categorized and tagged in DTP.
The Parasoft Multi-Language Pack extensions ship with example rule map files for each language (e.g., swiftlint-rulesmap.xml) in the <INSTALL >/rules/builtin directory. Rules are specified using the following format:
<builtin> <category name="Analyzer_name"> <category name="Category_name"> <rule id="rule_id" severity="sev"/>
You can modify this file to change mappings and add new rules:
- Either open the example rule map file or create a new one based on the example.
- Modify the rule entries as desired.
- If you created a new rule map file, adjust the rulemap value in the .properties configuration file for the third-party analysis tool located in the <INSTALL>/etc directory (e.g., swiftlint-settings.properties).
About the Rule Map Syntax
- A
name
property is required forcategory
tags. id
andseverity
properties are required for the rule element. Eachid
value must be unique within a given rule map file.- Multiple rules with the same
id
in the same rule map file, even if the rules are under different categories or analyzers, are not allowed. - If you are modifying rules that are shipped with the analyzer (rules in the builtin directory) only modify elements within the
<builtin>
element.
Adding a New Rule to the Rule Map
As an example of how to add a new rule to the rule map, assume that the following results XML file contains a violation for a rule that has not yet been referenced in your rule map file:
<?xml version="1.0" encoding="utf-8"?> <checkstyle version="4.3"> <file name="/surveyproject/example.swift"> <error line="3" column="40" severity="warning" message="There should be no space before and one after any comma."source="swiftlint.rules.comma" />
The error element shows the following information:
- line number and column where the violation was detected
- severity and message
- source attribute, which represents the error reported by the analyzer; SwiftLint in this example.
Below is the rule map XML file excerpt that defines the custom "COMMA" rule referenced above.
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <rules> <builtin> <category description=" SwiftLint" name="SWIFTLINT"> <category description=" Lint" name="LINT"> <rule header=" There should be no space before and one after any comma." id="COMMA"severity="2"/>
The builtin
element is provided for your convenience. For custom rules, you can create any tag you like (i.e., custom
).
The category element specifies SWIFTLINT
as the primary category. The subcategory is defined in a child category element (name="LINT"
) category, which is a category used by SwiftLint.
The rule
tag is the child of the subcategory, which contains the following properties:
header
- describes the use of the ruleid
- matches the source attribute in the error tag of the results xmlseverity
– describes the criticality you want to assign to this violation.
The error's severity is "warning"
, but Parasoft uses a scale of 1 (highest) to 5 (lowest) to indicate severity levels. You can change the severity level to any value within that range.
The full ID of this rule is SWIFTLINT. LINT.COMMA.
Additional Settings
You can modify the settings.properties file located in the installation directory to configure additional settings. The settings file is a plain text configuration file containing general properties (DTP settings, reporting preferences, logging preferences, etc.), as well as settings specific to the particular extension that you're using.
- General Extension Options
- Rules Settings
- Scope and Authorship Settings
- Report Settings
- Console and Logging Settings
- Git Source Control Settings
- Mercurial Source Control Settings
- Perforce Source Control Settings
- Subversion Source Control Settings
- Microsoft Team Foundation Server Source Control Settings
General Extension Options
Every extension defines several core settings in <ANALYZER_HOME>/etc/default-settings.properties. If you want to change the default values for these options, we recommend overriding them in your settings file, rather than editing the default-settings.properties file. You can configure the following settings:
rule.violation.limit.enabled
Set this option to true
if you want to limit the number of violations reported per rule. The default is false
.
rule.violations.limit
If rule.violation.limit.enabled is set to true
, this number is the maximum number of violations reported per rule. The default is 1000
.
scope.path.reject.wildcard
Specify a comma-separated list of file names, types, or extensions for which you don’t want to report violations. The following list is the default value for this property: *.so
, *.class
, *.obj
, *.jar
, *.exe
, *.dll
, *.lib
, *.pdb
, *.zip
, *.tgz
, *.tar
, *.gz
, *.a
, *.swf
, *.pdf
, *.pch
, *.bin
, *.wi
, **/bin/**/*.tmp
, **.parasoft.dat/**
, *.svn-base
, *.tscache
Any values specified are appended to the default setting. The default setting cannot be completely overridden.
scope.path.reject.regexp
Specify a regular expression that defines file names, types, or extensions for which you don’t want to report violations. There is no default setting.
Example:
scope.path.reject.regexp=^.*(?<!cs|CS)$
scope.path.accept.wildcard
Specify a comma-delimited list of wildcards that defines which files will be accepted by the scope filter.
The default settings for each analyzer include the appropriate filter options by default. For instance, the following setting is configured in the etc/tslint-settings.properties file by default:
scope.path.accept.wildcard=*.ts
The following settings is configured in the etc/jshint-settings.properties file by default:
scope.path.accept.wildcard=*.js,*.html
You can set this property in the localsettings.properties file to override the default settings for each analyzer.
Example:
scope.path.accept.wildcard=*.ts,**/*.ts,**/*.ts,**/src/**/*.ts
scope.path.accept.regexp
Specifies a regular expression that defines which files will be accepted by the scope filter. There is no default setting.
Example:
scope.path.accept.regexp=^.*(?<!js|JS)$
dtp.autoconfig
Set to true
to enable DTP to auto-configure the current installation with settings stored on DTP. Default is false
.
Rules Settings
You can configure the following settings related to code analysis rules.
rules.provider_<analyzer>.data
Specify the path to the code analysis rules used by the analyzer. The path will vary depending on the analyzer associated with the extension.
OCLint example:
rules.provider_oclint.data=/path/to/newrulemap/oclint-rulemap.xml
tslint example:
rules.provider_tslint.data=/path/to/newrulemap/tslint-rulemap.xml
Scope and Authorship Settings
These settings enable the system to correlate violations with information from source control.
scope.local
Enables/disables code authorship computation based on the local user and system files modification time. Default is true
.
scope.scontrol
Enables/disables code authorship computation based on data from a supported source control system. Default is false
.
scope.xmlmap
Enables/disables task assignment based on an XML mapping file. The mapping file defines how tasks should be assigned for particular files or sets of files. Default is false
.
scope.xmlmap.file
If scope.xmlmap is enabled, the setting specifies the path to the XML mapping file.
authors.ignore.case
Enables/disables author name case sensitivity. Default is false
.
authors.mappings.location
Specifies where the authorship mapping file is stored. Default is local
.
See authors.user and authors.mapping options for details.
If set to shared, you can define a path to the file in with the authors.shared.path setting. This enables you to specify a file location on DTP share.
authors.shared.path
Specifies the location of authors mapping file in DTP share.
Example:
authors.shared.path=xtest/authors_map.txt
authors.user<n>
Specifies an author by user name, email, and full name. Examples:
authors.user1=dan,dan@parasoft.com,Dan Stowe
authors.user2=jim,jim@parasoft.com,Jim White
authors.mapping<n>
Specifies a specific author mapping. Examples:
authors.mapping1=old_user,new_user
authors.mapping2=broken_user,correct_user
Report Settings
The following settings define the information presented in reports and the metadata associated with analysis results.
report.dtp.publish
Set to true
to enable the current installation to report test and analysis results to DTP. Default is false
.
report.dtp.publish.src
Determines whether tested source code is published to DTP server. You can use the following values:
off
: code is not published to DTP server.min
: publishes minimal part of sources. In most cases, source code without references to source control, e.g., auto-generated code, is published.full
: publishes all sources associated with the specified scope.
The default is full
when report.dtp.publish is enabled.
dtp.share.enabled
Enables/disables the connection to Team Server. The default is false
.
session.tag
Specifies a tag for the results from a code analysis/test session. The tag is a unique identifier for the specified analysis process made on a specified module. Reports for different sessions should be marked with different session tags.
build.id
Specifies a build identifier used to label results. It may be unique for each build but may also label more than one test sessions that were executed during a specified build.
The default settings is build-yyyy-MM-dd HH:mm:ss
report.assoc.url.<tag>
Generates links inside the HTML report that link associations. The URL is a query string containing an [%ID%]
placeholder for the PropertyAttribute
value.
report.partial
Enables/disables report generation when the full scope of the analysis is partially complete. The default settings is false
.
Setting to true
, for example, generates reports from analysis on a continuous incremental build that re-executes analysis only on modified files.
report.format
Specifies the report format. Use a comma separated list of formats to generate multiple formats. Default is xml
.
report.custom.extension
Specifies the report file extension of the XSL file for a custom format. To configure this property, set report.format to custom
and specify the location of an XSL file with the report.custom.xsl.file property.
report.custom.xsl.file
Specifies the location of the XSL file for a custom format. To configure this property, set the report.format to custom and specify a file extension using the report.custom.extension property.
report.location
Specifies the directory where report should be created.
report.developer_errors
Determines whether manager reports include details about developer errors. The default is true
.
report.developer_reports
Determines whether the system generates detailed reports for all developers (in addition to a summary report for managers). The default is false
.
report.authors_details
Determines whether the report includes an overview of the number and type of tasks assigned to each developer. The default is true
.
report.contexts_details
Determines whether the report includes an overview of the files that were checked or executed during testing. The default is false
.
report.associations
Enables/disables showing requirements, defects, tasks, and feature requests associated with a test in the report. The default is false
.
report.suppressed_msgs
Determines whether report includes suppressed messages. The default setting is false
.
report.metadata
Determines whether additional metadata about findings should be downloaded from DTP. Only findings that are already present on DTP are affected. The DTP server must also support the metadata service for this setting to have an effect. Default is true
.
report.active_rules
Determines if report contains a list of the rules that were enabled for the test. The default setting is false
.
report.rules
Specifies a directory for storing static analysis rules HTML files (retrieved by clicking the Printable Docs button in the Test Configuration's Static Analysis tab).
Examples:
report.rules=file:///C:/parasoft/gendoc/
report.rules=../gendoc/
report.scontrol
Configures the level of additional information from source control that should be included in the report. The property accepts the following values:
min
: repositories, file paths and revisionsfull
: Includes the same information asmin
but also includes task revisions and comments.
Default is off
.
report.test_params
Determines whether report includes test parameter details. The default setting is false
.
report.graph.start_date
Specifies start date for trend graphs that track static analysis task, test execution, and coverage. Use with report.graph.period.
report.graph.period
Determines the duration from the start date for trend graphs that track static analysis task, test execution, and coverage. Use with report.graph.start_date.
report.mail.enabled
Enables/disables report emails to developers and additional recipients specified with the report.mail.cc setting. If enabled, all developers that worked on project code will automatically be sent a report that contains the errors/results related to his or her work. The default setting is false
.
report.mail.server
Specifies the mail server used to send reports.
report.mail.subject
Specifies the subject line of the emails sent.
report.mail.username
report.mail.password
report.mail.realm
Specifies the settings for SMTP server authentication. The realm value is required only for those servers that authenticate using SASL realm.
report.mail.domain
Specifies the mail domain used to send reports.
report.mail.time_delay
Specifies a time delay between emailing reports (to avoid bulk email restrictions).
report.mail.from
Specifies the "from" line of the emails sent.
report.mail.attachments
Enables/disables sending reports as attachments. All components are included as attachments; before you can view a report with images, all attachments must be saved to the disk.
The default setting is false
.
report.mail.compact
Specifies how report information is delivered in the email. You can specify the following values.
trends
: email contains a trend graph, summary tables, and other compact data; detailed data is not included.links
: email only contains a link to a report available on DTP server.
This setting is not configured by default.
report.mail.format
Specifies content type for the email. The default setting is html
.
report.mail.cc
Specifies email address for sending comprehensive manager reports. Multiple addresses must be separated with a semicolon. This setting is commonly used to send reports to managers or architects, as well as select developers.
report.mail.include
Specifies the email addresses of developers that you want to receive developer reports. Multiple addresses must be separated with a semicolon. This setting is commonly used to send developer reports to developers if developer reports are not sent automatically (e.g., because the team is not using a supported source control system). This setting overrides addresses specified in report.mail.exclude.
report.mail.exclude
Specifies email addresses that should be excluded from automatically receiving reports.
report.mail.exclude.developers
Enables/disables report emails to developers not explicitly listed in the report.mail.cc setting. This setting is used to prevent reports from being mailed to individual developers. The default setting is false
.
report.mail.unknown
Specifies where to email reports for errors assigned to "unknown".
report.mail.on.error.only
Enables/disables email reports to the manager when an error is found or a fatal exception occurs. Developer emails are not affected by this setting; developer emails are sent only to developers who are responsible for reported errors. The default setting is false
.
report.setup.problems
Determines placement of setup problems section in report. The default setting is bottom
.
report.setup.problems.console
Determines whether setup problems will be printed on the console. The default setting is true
.
report.separate_vm
Specifies to generate reports is separate virtual machine. The default setting is false
.
report.separate_vm.launch.file
Specifies path to launch file which should be used during reports generation.
scontrol.timeout
Specifies timeout value for operations with source control. The default value is 60
.
scontrol.branch
Enables you to specify a custom name for the tested branch. This setting may be used to describe unique runs. If it is not specified, the tested branch is detected automatically based on code provided to analysis.
Console and Logging Settings
The following options enable you to specify the level of debugging information generated.
local.storage.dir
Specifies the temporary directory to save logs for debugging errors.
console.verbosity.level
Specifies the verbosity level for debugging. We recommend setting to high
.
logging.verbose
Enables/disables verbose logs. Verbose logs are stored in the xtest.log file in the location specified with the local.storage.dir setting. Verbose logging state persists across sessions (restored on application startup). The log is a rolling file with a fixed maximum size. A backup is created whenever the max size is reached.
Default is false
.
logging.scontrol.verbose
Enables/disables output from source control commands in verbose logs. The output from source control may include fragments of analyzed source code. Default is false
.
Git Source Control Settings
scontrol.rep<n>.type
Git repository type identifier.
scontrol.git.exec
Path to git executable. If not set, assumes git command is on the path.
scontrol.rep<n>.git.url
The remote repository URL (e.g., git://hostname/repo.git).
scontrol.rep<n>.git.workspace
The directory containing the local git repository.
Mercurial Source Control Settings
scontrol.rep<n>.type
Mercurial reposity type identifyer.
scontrol.hg.exec
Path to external client executable. Devault is hg
.
scontrol.rep<n>.hg.url
The remote repository URL (e.g., http://hostname/path).
scontrol.rep<n>.hg.workspace
The directory containing the local Mercurial repository.
Perforce Source Control Settings
scontrol.rep<n>.type
Perforce repository type identifier.
scontrol.perforce.exec
Path to external client executable (p4).
scontrol.rep<n>.perforce.host
Perforce server host.
scontrol.rep<n>.perforce.port
Perforce server port. Default port is 1666
.
scontrol.rep.perforce.login
Perforce user name.
scontrol.rep.perforce.password
Perforce password, optional if ticket is used for authentication.
scontrol.rep.perforce.client
The client workspace name as specified in the P4CLIENT environment variable or its equivalents. Root directory for specified workspace should be configured correctly for local machine.
Subversion Source Control Settings
scontrol.rep<n>.type
Subversion repository type identifier.
scontrol.svn.exec
Path to external client executable (svn).
scontrol.rep<n>.svn.url
Subversion URL specifies protocol, server name, port and starting repository path. Example:
svn://buildmachine.foobar.com/home/svn
scontrol.rep<n>.svn.login
Login name.
scontrol.rep.svn.password
Password (not encoded).
Microsoft Team Foundation Server Source Control Settings
scontrol.rep<n>.type
TFS repository type identifier.
scontrol.rep<n>.tfs.url
URL to TFS repository, e.g., http://localhost:8080/tfs
scontrol.rep<n>.tfs.login
TFS user name.
scontrol.rep<n>.tfs.password
TFS password.