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.

  1. Download the extension distribution on the machine running DTP.
  2. Copy the <ANALYZER_HOME>/rulesdoc/<analyzer_name> directory to the <DTP_HOME>/tomcat/webapps/grs/rulesdoc directory.
  3. 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. 

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:

  1. Either open the example rule map file or create a new one based on the example.
  2. Modify the rule entries as desired.
  3. 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

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:

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:

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

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 revisions
  • full: Includes the same information as min 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.