## Preface

© 2021 Vector Informatik GmbH - All rights reserved - https://www.vector.com/ - This material may not be reproduced, displayed, modified or distributed without the express prior written permission of the copyright holder. Squore is protected by an Interdeposit Certification registered with Agence pour la Protection des Programmes under the Inter Deposit Digital Number IDDN.FR.001.390035.001.S.P.2013.000.10600.

### Foreword

This edition of the Command Line Interface was released by Vector Informatik GmbH.

It is part of the user documentation of the Squore software product edited and distributed by Vector Informatik GmbH.

For information on how to use and configure Squore, the full suite of manuals includes:

User Manual

Target Audience

Squore Installation Checklist

New users before their first installation

Squore Getting Started Guide

End users, new users wanting to discover Squore features

Squore Command Line Interface

Continuous Integration Managers

Squore Configuration Guide

Squore configuration maintainers, Quality Assurance personnel

Squore Eclipse Plugin Guide

Eclipse IDE users

Squore Reference Manual

End Users, Squore configuration maintainers

Squore API Guide

End Users, Continuous Integration Managers

Squore Software Analytics Handbook

End Users, Quality Assurance personnel

### Licence

No part of this publication may be reproduced, transmitted, stored in a retrieval system, nor translated into any human or computer language, in any form or by any means, electronic, mechanical, magnetic, optical, chemical, manual or otherwise, without the prior written permission of the copyright owner, Vector Informatik GmbH. Vector Informatik GmbH reserves the right to revise this publication and to make changes from time to time without obligation to notify authorised users of such changes. Consult Vector Informatik GmbH to determine whether any such changes have been made. The terms and conditions governing the licensing of Vector Informatik GmbH software consist solely of those set forth in the written contracts between Vector Informatik GmbH and its customers. All third-party products are trademarks or registered trademarks of their respective companies.

### Warranty

Vector Informatik GmbH makes no warranty of any kind with regard to this material, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. Vector Informatik GmbH shall not be liable for errors contained herein nor for incidental or consequential damages in connection with the furnishing, performance or use of this material.

This edition of the Command Line Interface applies to Squore 21.0.2 and to all subsequent releases and modifications until otherwise indicated in new editions.

### Responsabilities

Approval of this version of the document and any further updates are the responsibility of Vector Informatik GmbH.

### Contacting Vector Informatik GmbH Product Support

If the information provided in this manual is erroneous or inaccurate, or if you encounter problems during your installation, contact Vector Informatik GmbH Product Support: https://portal.vector.com/

You will need a valid customer account to submit a support request. You can create an account on the support website if you do not have one already.

For any communication:

• support@vector.com

• Vector Informatik GmbH Product Support

Vector Informatik GmbH - Holderäckerstr. 36 / 70499 Stuttgart - Germany

The version of this manual included in your Squore installation may have been updated. If you would like to check for updated user guides, consult the Vector Informatik GmbH documentation site to consult or download the latest Squore manuals at https://support.squoring.com/documentation/latest. Manuals are constantly updated and published as soon as they are available.

## 1. Introduction

This document is the command line guide for Squore.

It is indented as a follow up to the Squore Getting Started Guide and will help you understand how to use Squore Agent to create and update projects using command line.

It is divided into several chapters, as detailed below:

• [chap_gettingstarted_agent] provides a basic introduction to Squore Agent and the examples provided with your Squore installation.

• [chap_cli_reference] provides a complete reference of all the command line options and parameters for creating projects.

• Repository Connectors covers the default Repository Connectors and the parameters to pass to Squore to use them.

• Data Providers is a reference guide to all the Data Providers shipped with Squore.

## 2. Installing Squore Agent

Squore Agent is a package that must be downloaded on every client computer that needs to perform local code analyses or trigger a remote analysis on Squore Server.

There are usually two ways to contemplate the deployment of Squore Agent:

1. As a way to analyse code and process data on a client machine and send the results to the server.

2. As a way to instruct the server to carry out an analysis of code and other input data.

Once downloaded, you are ready to create projects and trigger analyses on any Squore Server available from your client, see the Using Squore Agent section to know more about triggering analyses, remote or local.

Don’t forget to have a look at the section below to know more about the necessary prerequistes, where to download Squore Agent and such.

### Prerequisites

The absolute minimum necessary to run Squore Agent successfully is:

• One of the Supported Operating Systems (same as Squore Server’s list).

• A Java Runtime Environment version 11 (64-bits) (Java 8 is still supported, any other versions are not.)

Then, in case you plan to use Squore Agent as a way to analyse code and process data on the client machine, then additional packages will be required. Requirements will be the same as for a Squore Server. See the Squore Server prerequisites section to get the list of required and optionnal packages depending on your OS: Installation Prerequisites

 If your client is on Windows and the targeted Squore Server is on Linux, follow the instructions from Defining Server Dependencies section in order to retrieve Perl and TCL binaries.

There is no need to upgrade Squore Agent. A check is performed every time a project analysis is launched and the new binaries are downloaded automatically if necessary.

 Squore CLI installations before Squore 21, cannot be upgraded using the Squore Agent. Neither will they be compatible with Squore 21 and up, moving forward only the Squore Agent must be used.

### Uninstall

In order to completely remove Squore Agent from your system, just delete the squore-agent.jar file and any workspaces you created.

## 3. Using Squore Agent

Squore Agent allows you to create projects and trigger analyses on existing projects using the command line.

Synchronisation of the agent, its librairies and the configuration with the Squore Server is done automatically, if needed, upon each Squore Agent command line execution.

It is possible to use the same Squore Agent to trigger analyses on multiple Squore Server. In that case, dedicated folders are created in the agent workspace.

### Command Line Structure

Squore Agent command line can be divided in two separate parts, delimited by the "--" separator:

1. The left side, dedicated to the agent options

2. The right side, dedicated to the project’s build parameters

Triggering a project analysis on remote Squore Server
``java -jar squore-agent.jar -u demo http://localhost:8180/SQuORE_Server -- --commands="DELEGATE_CREATION" --name="Earth" --versionPattern="V#N1#" --wizardId="ANALYTICS" --dp="type=SQuORE" --repository="path=<SQUORE_HOME>/samples/c/Earth/V6"``
Showing help
``java -jar squore-agent.jar --help``

### Command Line Reference

#### Squore Agent Options

Here is the list of Squore Agent supported options and parameters:

Options
-c `FILE`, --config=`FILE`

To use a specific configuration file, config.xml.

-f, --force

To force configuration files and resources refresh.

-h, --help

To display command help information.

-u `USER`, --username=`USER`

To specify the username. Not required if the token is set.

-P `PASSWORD`, --password=`PASSWORD`

To specify the password associated with the username. Not required if the token is set.

-t `TOKEN`, --token=`TOKEN`

To specify a token, same as with the REST API. (Authentication and Security).

-s, --save-credentials

To save the user credentials to disk. If no user is specified, the current user of the OS is used.

-w `FOLDER`, --workspace=`FOLDER`

To specify the Squore Agent folder where all necessary files and resources will be downloaded. Default directory is where squore-agent.jar is located.

-x, --debug

To display debug information.

Parameters
<URL>

The Squore Server URL, default value is http://localhost:8180/SQuORE_Server.

#### Project Build Parameters

The easiest way to obtain the command line parameters for creating a project is to retrieve it from Squore Server GUI.

Indeed, from the GUI, create a new project and setup the parameters as needed, then at the bottom of the last page of the project creation Wizard, Confirmation, have a look at the "Squore agent command line" section :

Project parameters for command line use

From there, copy the project build parameters on the right side of the "--" separator and append them to the Squore Agent command line:

``java -jar /path/to/squore-agent.jar -u demo -- --commands="DELEGATE_CREATION" --name="myFirstCommandLineProject" --version="V1" --wizardId="ANALYTICS" --dp="type=SQuORE" ...``

Here is the list of available parameters:

Command
-c `"COMMAND"`, --commands=`"COMMAND"`

(mandatory, default='')

The list of commands to launch, which is a semicolon-separated string defining the commands to launch. Accepted values are:

• `PROCESS_CREATION`: to process project creation on client-side. With this option, Data Providers runs on the client side. the results are then sent to the server, which will perform the result analysis and will imports datas into the database.

• `DELEGATE_CREATION`: to send the project settings to the server to request a project creation

• `GENERATE_CONF_PARAMETERS`: to generate the command line options associated to all parameters found in the specified configuration file. It requires the 'projectConfFile' option to be defined.

• `CHECK_MODELS`: to check the validity of a model’s configuration. It requires the 'outputCheckModelsFile' option to be defined.

• `GENERATE_OUTPUT`: to generate the output data and statistics of the project’s creation. It should always be called after all other commands.

General
-n `"MyProject"`, --name=`"MyProject"`

(mandatory, default='')

Defines the name of the project that will be created.

-w `"ANALYTICS"`, --wizardId=`"ANALYTICS"`

(mandatory, default='')

The id of the wizard used to create the project.

--branch=`"MyBranchName"`

(optional, default='main')

Defines the project branch onto which the analysis will be executed. It is not possible to create branches from command line, only run analysis on existing branches.

--group=`"MyGroup"`

(optional, default='')

Defines the group that the project belongs to. Projects from the same group are displayed together in the project portfolios and the group can optionally be rated as a whole. Note that you can specify subgroups by adding a / in your group name: --group="prototype/phase1" will create a phase1 group under a prototype group.

-v `"V1"`, --version=`"V1"`

(optional, default='null')

Defines the label used for the version of this project. If not specified, the version pattern parameter is used to generate the version label instead.

--versionPattern=`"V#.N#"`

(optional, default='null')

Defines the pattern used to label the version automatically if no version parameter was passed.

 The versionPattern parameter allows specifying a pattern to create the version name automatically for every analysis. It supports the following syntax: #N#: A number that is automatically incremented #Nn#: A number that is automatically incremented using n digits #Y2#: The current year in 2-digit format #Y4#: The current year in 4-digit format #M#: The current month in two digit format #D#: The current day in two digit format #H#: The current hour in 24 hour format #MN#: The current minute in two digit format #S#: The current second in two digit format Any character other than # is allowed in the pattern. As an example, if you want to produce versions labelled build-198.2013-07-28_13h07m (where 198 is an auto-incremented number and the date and time are the timestamp of the project creation), you would use the pattern: build-#N3#.#Y4#-#M#-#D#_#H#h#MN#m
--versionDate=`"YYYY-MM-DDTHH:MM:SS"`

(optional, default='actual analysis time')

Allows specifying a date for the version that is different from the current date. This is useful when the charts on your dashboard haves axes or intervals that show dates instead of version names. Note that for every new analysis, the date must be after the date of the previous analysis.

--color=`"rgb(130,196,240)"`

(optional, default='randomly assigned')

Defines the color used to identify the project in the Squore user interface after its creation. The numbers define the numbers define the values for red, green and blue respectively. Note that if you do not specify a colour on the command line, a random colour will be picked.

-b `"true|false"`, --autoBaseline=`"true|false"`

(optional, default='true')

Allows to build a baseline version that will not be overwritten by a subsequent analysis. When set to false, every analysis overwrites the previous one, until a new baseline is created. If not set, this parameter defaults to true.

--useLastParams=`"true|false"`

(optional, default='false')

Allows to reuse all the parameters from the last known analysis on the project, whether it was executed from GUI, API or command line. Providing additional parameters will allow you to override the corresponding ones from last analysis.

-r `"type=REPOTYPE,opt1=value1,opt2=value2"`, --repository=`"type=REPOTYPE,opt1=value1,opt2=value2"`

(optional, multiple)

Used to specify repositories for sources. For more information about repositories syntax, refer to Repository Connectors. When using multiple source code repositories, each one musy have an alias=NodeName parameter that is used to create a folder containing the source code for the repository in the Artefact Tree.

-d `"type=DPName,dp_opt=dp_opt_value"`, --dp=`"type=DPName,dp_opt=dp_opt_value"`

(optional, multiple)

Used to specify information for Data Providers. For more information about individual Data Provider syntax, refer to Data Providers.

-sub `"true|false"`, --subFoldersAsVersions=`"true|false"`

(optional, default='false')

Loops on the repository path to create a version for each sub-folder using the sub-folder name as the version name. This options is only supported when using the FROMPATH Repository Connector.

Team
-q `"mike,DEVELOPER;peter,PROJECT_MANAGER"`, --teamUser=`"mike,DEVELOPER;peter,PROJECT_MANAGER"`

(optional, default='')

This semicolon-separated list of login,projectRoleID pairs is used to define a list of users who will be able to access the project when it is created.

Note that this option is taken into account when creating a new project but is ignored when creating a new version. In order to edit the list of users in a project team, you must use the Squore web interface.

Refer to the list of available projectRoleIDs in Squore by clicking Administration > Roles. This option can be combined with the teamGroup parameter if needed.

-g `"devUsers,DEVELOPER;management,GUEST"`, --teamGroup=`"devUsers,DEVELOPER;management,GUEST"`

(optional, default='')

This semicolon-separated list of group,projectRoleID pairs used to define a list of groups who will be able to access the project when it is created.

Note that this option is taken into account when creating a new project but is ignored when creating a new version. In order to edit the list of groups in a project team, you must use the Squore web interface.

Refer to the list of available projectRoleIDs in Squore by clicking Administration > Roles. This option can be combined with the teamUser parameter if needed.

Forms
-t `"TAGNAME=tagValue"`, --tag=`"TAGNAME=tagValue"`

(optional, multiple)

If the wizard allows tags (i.e. project attributes), then use the this parameter to inform the CLI of the tag values to use for this project.

-M `"id=BETA_RELEASE,date=2015/05/31,PROGRESS=95"`, --milestone=`"id=BETA_RELEASE,date=2015/05/31,PROGRESS=95"`

(optional, multiple)

Allows you to define a milestone in the project. This parameter accepts a date and a series of metrics with their values to specify the goals for this milestone. Note that this parameter allows you to add milestones or modify existing ones (if the ID provided already exists), but removing a milestone from a project can only be done from the web interface.

 You can also define milestones in your project file using a `Milestones` element in the `Wizard` section: `````` ``````
Rulesets
--rulesetTemplate=`"my template"`

(optional, default='null')

The name of the ruleset template created in the Analysis Model Editor that should be used for this analysis. For more information about ruleset templates, consult the Getting Started Guide.

-um `"/path/to/ruleset.xml"`, --updateModelFile=`"/path/to/ruleset.xml"`

(optional, default='null')

The XML file listing the changes to be applied to the standard analysis model for this analysis. The XML file contains a list of rules with their status and categories, as shown below:

``````<UpdateRules>
<UpdateRule measureId="R_NOGOTO" disabled="true" categories="SCALE_SEVERITY.CRITICAL"/>
</UpdateRules>``````
 This parameter is only read and applied when creating the first version of a project, for models where editing the ruleset is allowed. You may find it more flexible to work with named templates created in the Analysis Model Editor and specified on the command line with the --rulesetTemplate parameter.
Output
-o `"/path/to/output.xml"`, --outputFile=`"/path/to/output.xml"`

(optional, default='null')

The absolute path to the output file generated by the analysis

-m `"/path/to/validator.xml"`, --outputCheckModelsFile=`"/path/to/validator.xml"`

(optional, default='null')

Defines the absolute path to the output check models file generated by the CHECK_MODELS command.

-print `"true|false"`, --printOutput=`"true|false"`

(optional, default='false')

Redirect the engine’s output to the standard output.

--keepDataFiles=`"true|false"`

(optional, default='false')

Instructs Squore to keep or discard analysis files from old versions or only for the latest analysis. Note that this behaviour only affects disk space on the server, not the analysis results

-f `"FILTER_OPTS"`, --filter=`"FILTER_OPTS"`

(optional, default='')

This semicolon-separated string of triplets {artefactType,filterType,filterValue}. In order to export the measure LC, a DESCR info the indicator MAIN at application level, pass -f "APPLICATION,MEASURE,LC;APPLICATION,INFO,DESCR;APPLICATION,INDICATOR_LEVEL,MAIN;".

The artefact type ALL_TYPES and the filter types ALL_DEFECT_REPORTS, ALL_MEASURES, ALL_INDICATORS_LEVELS, ALL_INDICATORS_RANKS, ALL_BASE_FINDINGS, ALL_BASE_LINKS, ALL_COMPUTED_LINKS and ALL_INFOS can also be used, followed by an empty filter value. In order to export all measures at application level in the output file, pass the parameter --filter="APPLICATION,ALL_MEASURES,;". In order to export all indicators for all artefact types in the output file, pass the parameter --filter="ALL_TYPES,ALL_INDICATORS_LEVELS,;"

Other
-x `"/path/to/project_conf.xml"`, --projectConfFile=`"/path/to/project_conf.xml"`

(optional, default='null')

The XML file defining the project settings. When using a combination of a project file and some parameters passed from the command line, the command line parameters override the project file ones.

-ez `"/path/to/project/data"`, --exportZip=`"/path/to/project/data"`

(optional, default='null')

This parameter can be used to import a debug zip file as a new project. When this parameter is used, a new project is created using the paremeters in the conf.xml file inside the debug package, with any other parameter passed on the command line overriding the ones from the configuration file. Instead of a debug zip file, you can pass an absolute path to a project data folder to launch an analysis of all the version folders contained in that folder.

When using this option, you should pass --strictMode="false", -S false to disable some internal data integrity checks and change the project owner if needed using the --owner="admin", -O "admin" to se the new project owner (requires admin privileges).

 This functionality is mostly used to test out how a project is rated in a different model, however it is not recommended for use in production since it will not replicate the following data from the old project to the new project: All comments and discussion threads Action Item statuses History of changes in forms and relaxation comments Relaxations and exclusions statuses of artefacts and findings

The rest of the parameters that you will pass to the Engine to create projects are specific to Repository Connectors and Data Providers and are detailed respectively in the Repository Connectors and Data Providers.

-?, --help

(optional, default='false')

Displays help and exits.

-?cmd, --help:commands

(optional, default='false')

Displays help about the available commands.

### Exit Codes

After a successful or unsuccessful run, the CLI returns an exit code from this list:

0

OK - The operation completed successfully.

1

Client creation error - There was an error launching the client process.

2

Configuration error - This could be due to an unreachable configuration file or a parameter set to an invalid value.

3

Problem while launching one of the commands - One of the commands failed to complete successfully. The console should provide information about what exactly failed.

4

Engine error - The client failed to launch the analysis. More details about this error are available in the client console and in the server logs.

## 4. Managing Credentials

Using Squore Agent, it is possible to save your credentials to disk as well as encrypt them using a master key.

Storing credentials on disk, will help avoid typing your password every time you create a project, and also avoid saving the password in your script files.

Credentials and master key are stored in respective files, credentials.xml and credentialsSecurity.xml, located in folder:

### Encrypting Credentials

It is possible to define a master key in order to encrypt the credentials defined in the credentials.xml file.

To define the master key simply execute the following command:

``java -jar squore-agent.jar http://localhost:8180/SQuORE_Server --encrypt-master-key <your-master-key>``

The file credentialsSecurity.xml will be generated containing the encrypted master key:

``````<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<credentialsSecurity>
<masterKey>{t/+kctF9r6gHitDsnLrWWQcxmGESPbuISPnnJsTNqZ8=}</masterKey>
</credentialsSecurity>``````

Then, every credentials added using Squore Agent will be encrypted in the credentials.xml file:

``````<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<credentials>
<server>
<id>http://localhost:8180/SQuORE_Server/</id>
<credential>
<token>eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1aWQiOjIsImlhd[...]</token>
</credential>
</server>
<server>
<id>http://svn/server/url/project/trunk/</id>
<credential>
</credential>
</server>
...
</credentials>``````
 If you want to clear the master key, simply remove the file $HOME/.squore/credentialsSecurity.xml on Linux or %USERPROFILE%\.squore\credentialsSecurity.xml on Windows. ### Migrating Old Credentials Format Old credentials format stored in file .squorerc, can be migrated to the new credentials.xml format. Just execute the following command: ``java -jar squore-agent.jar http://localhost:8180/SQuORE_Server --migrate-legacy-data``  If the credentials already exists in the credentials.xml file, they will not be replaced. ## 5. Advanced Configuration ### Defining Server Dependencies If your Squore Server is on Linux and your Squore Agent is installed on Windows, the Squore Agent won’t be able to download Perl and TCL librairies from Squore Server. To overcome this limitation, you can define a dependencies folder in Squore Server config.xml file, as follow : ``````<?xml version="1.0" encoding="utf-8" standalone="yes"?> <squore type="server" version="1.3"> ... <workspace directory="<SQUORE_HOME>/squore-data/workspace" /> <dependencies directory="/path/to/folder/dependencies"/> </squore>`````` This folder must contain the Perl and TCL Windows packages for Squore, which you can download from Vector website :  If you don’t have access to Squore Server, you can always download the packages and extract them on the Squore Agent machine. And then define the executables path in the config.xml file of Squore Agent. See the Adding config.xml File section below. ### Adding config.xml File An optional config.xml file can be defined in the Squore Agent workspace folder, in order to define your own Perl and TCL paths as well as data folders. Below is an example of a full config.xml file with parameters default values for Windows: ``````<?xml version="1.0" encoding="utf-8" standalone="yes"?> <squore type="client" version="2.0"> <paths> <path name="perl.dir" path="<SQUORE_HOME>\tools\perl"/> <path name="tclsh.dir" path="<SQUORE_HOME>\tools\tclsh"/> <path name="squore.path.svn" path="D:\Apps\svn\svn.exe"/> </paths> <tmp directory="<SQUORE_HOME>/data/temp"/> <projects directory="<SQUORE_HOME>/data/projects"/> <sources directory="<SQUORE_HOME>/data/temp/sources"/> </squore>``````  On Linux environments, only the Perl and TCL paths are different. Default values are the standard executable folders. ### Using Java System Properties Using java system properties to specify the paths to the tmp, projects and sources folders is useful if you want the Squore Agent installation to work for multiple users. See the example below : ``````<?xml version="1.0" encoding="utf-8" standalone="yes"?> <squore type="client" version="2.0"> <tmp directory="${java.io.tmpdir}/squore-${user.name}"/> <projects directory="${user.home}/.squore/projects"/>
<sources directory="${java.io.tmpdir}/sources""/> </squore>``````  Java system properties correspondance :${user.home} corresponds to $HOME on Linux and %APPDATA% on Windows${java.io.tmpdir} corresponds to /tmp on Linux and %TEMP% on Windows

### Setting up HTTPS

If HTTPS redirection is setup on your Squore server then the HTTPS URL must be used in the command line.

For Java to be able to trust/certify the connection with the server, you also need to add the SSL certificate in the Java truststore of the client machine hosting Squore Agent.

Java default truststore is a cacert file located in the java.home/lib/security directory. Where java.home is the runtime environment’s directory.

 The default password of Java default truststore is changeit.

Refer to the Import a certificate section to know how to import the certificate in the truststore.

## Appendix A: Repository Connectors

### ClearCase

#### Description

IBM Rational ClearCase is a software configuration management solution that provides version control, workspace management, parallel development support, and build auditing. The command executed on the server to check out source code is: $cleartool$view_root_path $view$vob_root_path.

 Prior to using this repository connector, the path to the cleartool command has to be configured in the config.xml file located in the root directory of the Squore server or the Squore client: ````

#### Usage

ClearCase has the following options:

• View root path (`view_root_path`, mandatory, default: /view): Specify the absolute path of the ClearCase view.

• Vob Root Path (`vob_root_path`, mandatory, default: /projets): Specify the absolute path of the ClearCase vob.

• View (`view`): Specify the label of the view to analyse sources from. If no view is specified, the current ClearCase view will be used automatically, as retrieved by the command cleartool pwv -s.

• Server Display View (`server_display_view`): When viewing source code from the Explorer after building the project, this parameter is used instead of the view parameter specified earlier. Leave this field empty to use the same value as for view.

• Sources Path (`sub_path`): Specify a path in the view to restrict the scope of the source code to analyse. The value of this field must not contain the vob nor the view. Leave this field empty to analyse the code in the entire view. This parameter is only necessary if you want to restrict to a directory lower than root.

The full command line syntax for ClearCase is:

``-r "type=ClearCase,view_root_path=[text],vob_root_path=[text],view=[text],server_display_view=[text],sub_path=[text]"``

### CVS

#### Description

The Concurrent Versions System (CVS), is a client-server free software revision control system in the field of software development.

For more details, refer to http://savannah.nongnu.org/projects/cvs.

 The following is a list of commands used by the CVS Repository Connector to retrieve sources: ``cvs -d $repository export [-r$branch] $project`` ``cvs -d$repository co -r $artefactPath -d$tmpFolder``

#### Usage

CVS has the following options:

• Repository (`repository`, mandatory): Specify the location of the CVS Repository.

• Project (`project`, mandatory): Specify the name of the project to get files from.

• Tag or Branch (`branch`): Specify the tag or branch to get the files from.

The full command line syntax for CVS is:

``-r "type=CVS,repository=[text],project=[text],branch=[text]"``

### Folder Path

#### Description

The simplest method to analyse source code in Squore is to provide a path to a folder containing your code.

 Remember that the path supplied for the analysis is a path local to the machine running the analysis, which may be different from your local machine. If you analyse source code on your local machine and then send results to the server, you will not be able to view the source code directly in Squore, since it will not have access to the source code on the other machine. A common workaround to this problem is to use UNC paths (\\Server\Share, smb://server/share…​) or a mapped server drive in Windows.

#### Usage

Folder Path has the following options:

• Datapath (path, mandatory):

• Absolute Path: the absolute path to the folder containing the files you want to include in the analysis. The path specified must be accessible from the server and user must have Access Server Resources permission.

• Authorized Paths: a list of server paths accessible for all users, regardless of the Access Server Resources permission. This list can only be configured by a Squore administrator : Configure Authorized Server Paths.

The full command line syntax for Folder Path is:

``-r "type=FROMPATH,path=[text]"``

### Folder (use GNATHub)

#### Description

Retrieve Sources from a folder on the server, use GNATHub to limit the files (compatible with GNAT Pro versions 7.4.2 up to 18.2).

 This Repository Connector will only be available after you configure your server or client config.xml with the path to your gnathub executable with a definition. Consult the Configuration Manual for more information about referencing external executables.

#### Usage

Folder (use GNATHub) has the following options:

• Path of the source files (`path`): Specify the absolute path to the files you want to include in the analysis. The path specified must be accessible from the server.

• Path of the gnathub.db file (`gnatdb`): Specify the absolute path of the gnathub.db file.

• Root path for sources in the GNAT DB (`gnat_root`): Specify the root path for sources in the GNAT DB

The full command line syntax for Folder (use GNATHub) is:

``-r "type=GNAThub,path=[text],gnatdb=[text],gnat_root=[text]"``

### Git

#### Description

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

For more details, refer to http://git-scm.com/.

 Prior to using this repository connector, the path to the git command have to be configured in the config.xml file located in the root directory of the Squore server or the Squore client: ```` The following is a list of commands used by the Git Repository Connector to retrieve sources: ``git clone [$username:$password@]$url$tmpFolder`` ``git checkout $commit`` ``git log -1 "--format=%H"`` ``````git config --get remote.origin.url`````` ``git clone [$username:$password@]$url $tmpFolder`` ``git checkout$commit`` ``git fetch`` ``git --git-dir=$gitRoot show$artefactPath`` Git 1.7.1 is known to fail with a fatal: HTTP request failed error on CentOS 6.9. For this OS, it is recommended to upgrade to git 2.9 as provided by software collections on https://www.softwarecollections.org/en/scls/rhscl/rh-git29/ and point to the new binary in git_config.tcl or make the change permanent as described on https://access.redhat.com/solutions/527703.

#### Usage

Git has the following options:

• URL (`url`, mandatory): URL of the git repository to get files from. The local, HTTP(s), SSH and Git protocols are supported.

• Branch or commit (`commit`): This field allows specifying the SHA1 of a commit or a branch name. If a SHA1 is specified, it will be retieved from the default branch. If a branch label is specified, then its latest commit is analysed. Leave this field empty to analyse the latest commit of the default branch.

• Sub-directory (`subDir`): Specify a subfolder name if you want to restrict the analysis to a subpath of the repository root.

• Authentication (`useAccountCredentials`, default: NO_CREDENTIALS): Possible values for authentication are

• No credentials: Used when the underlying Git is open and does not require authetication

• Use my Squore credentials: If the login/password are the same between Squore and the underlying git

• Username (`username`):

• Password (`password`):

The full command line syntax for Git is:

``-r "type=Git,url=[text],commit=[text],subDir=[text],useAccountCredentials=[multipleChoice],username=[text],password=[password]"``

### Perforce

#### Description

The Perforce server manages a central database and a master repository of file versions. Perforce supports both Git clients and clients that use Perforce’s own protocol.

For more details, refer to http://www.perforce.com/.

 The Perforce repository connector assumes that the specified depot exists on the specified Perforce server, that Squore can access this depot and that the Perforce user defined has the right to access it. The host where the analysis takes place must have a Perforce command-line client (p4) installed and fully functional. The P4PORT environment variable is not read by Squore. You have to set it in the form. The path to the p4 command can be configured in the config.xml file located in the root directory of the Squore server or the Squore client: ```` The following is a list of commands used by the Perforce Repository Connector to retrieve sources: ``p4 -p $p4port [-u username] [-P password] client -i <$tmpFolder/p4conf.txt`` ``p4 -p $p4port [-u username] [-P password] -c$clientName sync "$depot/...@$label"`` ``p4 -p $p4port [-u username] [-P password] client -d$clientName`` ``p4 -p $p4port [-u username] [-P password] print -q -o$outputFile $artefactPath`` The format of the p4conf.txt file is: ``````Client:$clientName Root: $tmpFolder Options: noallwrite noclobber nocompress unlocked nomodtime normdir SubmitOptions: submitunchanged view:$depot/... //$clientName/...`````` #### Usage Perforce has the following options: • P4PORT (`p4port`, mandatory): Specify the value of P4PORT using the format [protocol:]host:port (the protocol is optional). This parameter is necessary even if you have specified an environment variable on the machine where the analysis is running. • Depot (`depot`, mandatory): Specify the name of the depot (and optionnally subforders) containing the sources to be analysed. • Revision (`label`): Specify a label, changelist or date to retrieve the corresponding revision of the sources. Leave this field empty to analyse the most recent revision fo the sources. • Authentication (`useAccountCredentials`, default: NO_CREDENTIALS): Possible values for authentication are • No credentials: Used when the underlying system is open and does not require authentication • Use my Squore credentials: If the login/password are the same between Squore and the underlying system • Define credentials: To be prompted for login/password • Username (`username`): Username to use if authentication is set to "Define credentials" • Password (`password`): Password to use if authentication is set to "Define credentials" The full command line syntax for Perforce is: ``-r "type=Perforce,p4port=[text],depot=[text],label=[text],useAccountCredentials=[multipleChoice],username=[text],password=[password]"`` ### PTC Integrity #### Description This Repository Connector allows analysing sources hosted in PTC Integrity, a software system lifecycle management and application lifecycle management platform developed by PTC. For more details, refer to http://www.ptc.com/products/integrity/.  Prior to using this repository connector, the paths to the si and mksAPIViewer commands have to be configured in the config.xml file located in the root directory of the Squore server or the Squore client: `````` `````` For versions that do not support the --xmlapi option for command viewproject, you can also turn off this method of retrieving file information. This value can be changed in the file /configuration/repositoryConnectors/MKS/form.xml if needed. #### Usage PTC Integrity has the following options: • Server Hostname (`hostname`, mandatory): Specify the name of the Integrity server. This value is passed to the command line using the parameter --hostname. • Port (`port`): Specify the port used to connect to the Integrity server. This value is passed to the command line using the parameter --port. • Project (`project`): Specify the name of the project containing the sources to be analysed. This value is passed to the command line using the --project parameter. • Revision (`revision`): Specify the revision number for the sources to be analysed. This value is passed to the command line using the --projectRevision parameter. • Scope (`scope`, default: name:.c,name:*.h)*: Specifies the scope (filter) for the Integrity sandbox extraction. This value is passed to the command line using the --scope parameter. • Authentication (`useAccountCredentials`, default: NO_CREDENTIALS): Possible values for authentication are • No credentials: Used when the underlying system is open and does not require authentication • Use my Squore credentials: If the login/password are the same between Squore and the underlying system • Define credentials: To be prompted for login/password • Username (`username`): Username to use if authentication is set to "Define credentials" • Password (`password`): Password to use if authentication is set to "Define credentials" In addition the following options are avaiable on command line: • `mksTriesDisconnectOnConnectFailure`(default: true): Set to true to try a disconnect and then a new connect when "si connect" failed • `xmlapi`(default: true): Set to true if your MKS version support option --xmlapi for command viewproject The full command line syntax for PTC Integrity is: ``-r "type=MKS,hostname=[text],port=[text],project=[text],revision=[text],scope=[text],useAccountCredentials=[multipleChoice],username=[text],password=[password],mksTriesDisconnectOnConnectFailure=[text],xmlapi=[text]"`` ### SVN #### Description Connecting to an SVN server is supported using svn over ssh, or by using a username and password. For more details, refer to https://subversion.apache.org/.  Prior to using this repository connector, the path to the svn command has to be configured in the config.xml file located in the root directory of the Squore server or the Squore client: ```` The following is a list of commands used by the SVN Repository Connector to retrieve sources. Command parameters can be changed in the file /configuration/repositoryConnectors/SVN/form.xml if needed. See also below command line options svn_export, svn_info, svn_external and svn_cmd_timeout): ``svn info --xml --non-interactive --trust-server-cert --no-auth-cache [--username$username] [--password $password] [-r$revision] $url`` ``svn export --force --non-interactive --trust-server-cert --no-auth-cache [--username$username] [--password $password] [-r$revision] $url`` This Repository Connector includes a hybrid SVN mode avoiding an extra checkout of source tree when using the `local_path` attribute. Consult the reference below for more details. #### Usage SVN has the following options: • URL (`url`, mandatory): Specify the URL of the SVN repository to export and analyse. The following protocols are supported: svn://, svn+ssh://, http://, https:// . • Revision (`rev`): Specify a revision number in this field, or leave it blank to analyse files at the HEAD revision. • External references (`externals`, default: exclude): Specify if when extracting sources from SVN the system should also extract external references. • Sources are already extracted in (`local_path`): Specify a path to a folder where the sources have already been extracted. When using this option, sources are analysed in the specified folder instead of being checked out from SVN. At the end of the analysis, the url and revision numbers are attached to the analysed sources, so that any source code access from the web interface always retrieves files from SVN. This mode is mostly used to save an extra checkout in some continuous integration scenarios. • Authentication (`useAccountCredentials`, default: NO_CREDENTIALS): Possible values for authentication are • No credentials: Used when the underlying system is open and does not require authentication • Use my Squore credentials: If the login/password are the same between Squore and the underlying system • Define credentials: To be prompted for login/password • Username (`username`): Username to use if authentication is set to "Define credentials" • Password (`password`): Password to use if authentication is set to "Define credentials" In addition the following options are avaiable on command line: • `svn_export`(default: export --force --non-interactive --trust-server-cert --no-auth-cache): Non interactive SVN export command to use for extrating sources from SVN repository. • `svn_info`(default: info --xml --non-interactive --trust-server-cert --no-auth-cache): Non interactive SVN command to get information in xml format. • `svn_external`(default: propget svn:externals -R --non-interactive --trust-server-cert --no-auth-ca…​): Non interactive SVN command to get externa information recursiveley. • `svn_cmd_timeout`(default: 3600000): Timeout to stop SVN commands which could block. The full command line syntax for SVN is: ``-r "type=SVN,url=[text],rev=[text],externals=[multipleChoice],local_path=[directory],useAccountCredentials=[multipleChoice],username=[text],password=[password],svn_export=[text],svn_info=[text],svn_external=[text],svn_cmd_timeout=[text]"`` ### Synergy #### Description Rational Synergy is a software tool that provides software configuration management (SCM) capabilities for all artifacts related to software development including source code, documents and images as well as the final built software executable and libraries. For more details, refer to https://www.ibm.com/products/rational-synergy.  Prior to using this repository connector, the path to the ccm command have to be configured in the config.xml file located in the root directory of the Squore server or the Squore client: ```` The Synergy Repository Connector assumes that a project already exists and that the Synergy user defined has the right to access it. The host where the analysis takes place must have Synergy installed and fully functional. Note that, using credentials is only supported on Windows, so use the NO_CREDENTIALS option when Synergy runs on a Linux host (consult IBM’s documentation for more details). The following is a list of commands used by the Synergy Repository Connector to retrieve sources: ``ccm start -d$db -nogui -m -q [-s $server] [-pw$password] [-n $user -pw password]`` ``ccm prop "$path@$projectSpec"`` ``ccm copy_to_file_system -path$tempFolder -recurse $projectSpec`` ``ccm cat "$artefactPath@$projectSpec"`` ``ccm stop`` #### Usage Synergy has the following options: • Server URL (`server`): Specify the Synergy server URL, if using a distant server. If specified, the value is used by the Synergy client via the -s parameter. • Database (`db`, mandatory): Specify the database path to analyse the sources it contains. • Project Specification (`projectSpec`, mandatory): Specify the project specification for the analysis. Source code contained in this project specification will be analysed recursively. • Subfolder (`subFolder`): Specify a subfolder name if you want to restrict the scope of the analysis to a particular folder. • Include Subprojects (`subProject`, default: yes): This option creates work area copies for the specified projects and all subprojects. If this option is not on, subprojects are ignored. • Ignore links (`ignoreLinks`, default: no): This option is used to ignore links to subprojects. This option is valid only on Linux systems. • XML mapping file (`mappingFile`): Specify the path to the XML file used to map files in the database to the file system. • Authentication (`useAccountCredentials`, default: NO_CREDENTIALS): Note that, as stated in IBM's documentation, using credentials is only supported on Windows. The "No Credentials" option must be used when Synergy runs on a Linux host. For more information, consult IBM Rational Synergy documentation. • Username (`username`): Username to use if authentication is set to "Define credentials" • Password (`password`): Password to use if authentication is set to "Define credentials" In addition the following options are avaiable on command line: • `ccm_home`: Configure Environment - set the environment variable CCM_HOME • `loginSCA`: Set unique login for Source Code Access (only for linux), it is needed to save password in credentials. • `mappingScript`: Set a mapping script if any available. When a maping script is available a mapping file associated to the project can be provided. The full command line syntax for Synergy is: ``-r "type=Synergy,server=[text],db=[text],projectSpec=[text],subFolder=[text],subProject=[multipleChoice],ignoreLinks=[multipleChoice],mappingFile=[text],useAccountCredentials=[multipleChoice],username=[text],password=[password],ccm_home=[text],loginSCA=[text],mappingScript=[text]"`` ### TFS #### Description Team Foundation Server (TFS) is a Microsoft product which provides source code management, reporting, requirements management, project management, automated builds, lab management, testing and release management capabilities. This Repository Connector provides access to the sources hosted in TFS’s revision control system.  The TFS repository connector (Team Foundation Server - Team Foundation Version Control) assumes that a TFS command-line client is installed and fully functional on the machine where the analysis runs. Two types of clients are supported: Team Explorer Everywhere (the java client, enabled by default) and Visual Studio Client (tf.exe). Prior to using this repository connector, ensure that you have configured it to use the right client by adjusting settings in /configuration/repositoryConnectors/TFS/form.xml file (three tags have to be configured: clientCmd, argType and viewerCmd). The Repository Connector form must be filled according to the TFS standard (eg. the Project Path must begin with the '$' character…​). Note that this repository connector works with a temporary workspace that is deleted at the end of the analysis. The following is a list of commands used by the TFS Repository Connector to retrieve sources (this example uses the Windows client): ``tf.exe workspace [/login:$username,$password] /server:$url /noprompt /new$workspace`` ``tf.exe workfold [/login:$username,$password] /map $path$tempFolder /workspace:$workspace`` ``tf.exe get [/login:$username,$password] /version:$version /recursive /force $path`` ``tf.exe workspace [/login:$username,$password] /delete$workspace`` The following command is used when viewing sources in the web interface: ``tf.exe view [/login:$username,$password] /server:$artefactPath`` When using the Java Team Explorer Everywhere client, / is replaced by - and the view command is replaced by print. #### Usage TFS has the following options: • URL (`URL`, mandatory): Specify the URL of the TFS server. • Path (`path`, mandatory): Path the project to be analysed. This path usually starts with$.

• Version (`version`): Specify the version of the sources to analyse. This field accepts a changeset number, date, or label. Leave the field empty to analyse the most recent revision of the sources.

• Authentication (`useAccountCredentials`, default: NO_CREDENTIALS): Possible values for authentication are

• No credentials: Used when the underlying system is open and does not require authentication

• Use my Squore credentials: If the login/password are the same between Squore and the underlying system

• Username (`username`): Username to use if authentication is set to "Define credentials"

• Password (`password`): Password to use if authentication is set to "Define credentials"

In addition the following options are avaiable on command line:

• `clientCmd`(default: tf): Set the Team Foundation Version Control Client Name, it is generally tf but can be "cmd /c tf.cmd" on windows with Team Explorer Everywhere. Please add also the path if the command is not in your PATH environment variable

• `argType`(default: -): Set the Argument passing character

• Team Explorer Everywhere: "-" (eg. tf workspace -new myworkspace)

• Visual Studio Client: "/" (eg. tf workspace /new myworkspace)

• `viewerCmd`(default: print): Set the TFS viewer command

• Team Explorer Everywhere command : print

• Visual Studio tf command : view

The full command line syntax for TFS is:

``-r "type=TFS,URL=[text],path=[text],version=[text],useAccountCredentials=[multipleChoice],username=[text],password=[password],clientCmd=[text],argType=[text],viewerCmd=[text]"``

#### Description

This Repository Connector allows you to upload a zip file containing your sources to analyse. Select a file to upload in the project wizard and it will be extracted and analysed on the server.

 The contents of the zip file are extracted into Squore Server’s temp folder. If you want to uploaded files to persist, contact your Squore administrator so that the uploaded zip files and extracted sources are moved to a location that is not deleted at each server restart.

#### Usage

This Repository Connector is only available from the web UI, not from the command line interface.

### Using Multiple Nodes

Squore allows using multiple repositories in the same analysis. If your project consists of some code that is spread over two distinct servers or SVN repositories, you can set up your project so that it includes both locations in the project analysis. This is done by labelling each source code node before specifying parameters, as shown below

``````-r "type=FROMPATH,alias=Node1,path=/home/projects/client-code"
-r "type=FROMPATH,alias=Node2,path=/home/projects/common/lib"``````

Note that only alpha-numeric characters are allowed to be used as labels. In the artefact tree, each node will appear as a separate top-level folder with the label provided at project creation.

Using multiple nodes, you can also analyse sources using different Repository Connectors in the same analysis:

``````-r "type=FROMPATH,alias=Node1,path=/home/projects/common-config"

## Appendix B: Data Providers

This chapter describe the available Data Providers and the default parameters that they accept via the Command Line Interface.

### AntiC

#### Description

AntiC is a part of the jlint static analysis suite and is launched to analyse C and C++ source code and produce findings.

For more details, refer to http://jlint.sourceforge.net/.

 On Linux, the antiC executable must be compiled manually before you run it for the first time by running the command: ``# cd {squore_home}/addons/tools/Antic_auto/bin/ && gcc antic.c -o antic``

#### Usage

AntiC has the following options:

• Source code directory to analyse (`dir`): TAG.dir.DESCR = Leave this parameter empty if you want to analyse all sources from repository connectors specified for the project.

In addition the following options are avaiable on command line:

• `antiC`: The full path to the AntiC executable can be provided with this option if it is not located as specified above.

The full command line syntax for AntiC is:

``-d "type=Antic_auto,dir=[directory],antiC=[text]"``

### Automotive Coverage Import

#### Description

Automotive Coverage Import provides a generic import mechanism for coverage results at function level.

#### Usage

Automotive Coverage Import has the following options:

• CSV file (`csv`): Enter the path to the CSV containing the coverage data.

The expected format of each line contained in the file is PATH;NAME;TESTED_C1;OBJECT_C1;TESTED_MCC;OBJECT_MCC;TESTED_MCDC;OBJECT_MCDC

The full command line syntax for Automotive Coverage Import is:

``-d "type=Automotive_Coverage,csv=[file]"``

### Automotive Tag Import

#### Description

This data provider allows setting values for attributes in the project.

#### Usage

Automotive Tag Import has the following options:

• CSV file (`csv`): Specify the path to the file containing the metrics.

The full command line syntax for Automotive Tag Import is:

``-d "type=Automotive_Tag_Import,csv=[file]"``

### Axivion

#### Description

Import Findings from Axivion

For more details, refer to http://www.axivion.com.

#### Usage

Axivion has the following options:

• CSV File (`csv`): Specify the CSV file which contains the findings results (MISRA, Coding Style…​)

In addition the following options are avaiable on command line:

• `logLevel`(default: INFO): Specify the log level to be used (ALL, DEBUG, INFO, WARN, ERROR, FATAL, OFF, TRACE) the default is INFO

The full command line syntax for Axivion is:

``-d "type=bauhaus,csv=[file],logLevel=[text]"``

### BullseyeCoverage Code Coverage Analyzer

#### Description

BullseyeCoverage is a code coverage analyzer for C++ and C. The coverage report file is used to generate metrics.

For more details, refer to http://www.bullseye.com/.

#### Usage

BullseyeCoverage Code Coverage Analyzer has the following options:

• HTML report (`html`): Specify the path to the HTML report file generated by BullseyeCoverage.

The full command line syntax for BullseyeCoverage Code Coverage Analyzer is:

``-d "type=BullseyeCoverage,html=[file]"``

### CANoe

#### Description

Import data from CANoe XML test results

#### Usage

CANoe has the following options:

• Results folder (`dir`): Specify the folder containing XML test results files from CANoe.

• Test path (`testPath`, default: Tests): Define test path (for example Test/HIL Test), by default the value is Tests.

• Import Traceability Matrix from vTESTstudio? (`import_traceability_matrix`, default: false): Traceability matrix file (vtc-tso file) can be generated from vTESTstudio. Using the matrix file will automatically link Tests and requirements)

• Traceability File (vtc-tso) (`traceability_file`): Traceability File (vtc-tso)

• Reset all "Review" States? (`reset_review`, default: false): This option reset all "Review" information which have been filled in the GUI. Initialize the review state allows to start a new analysis review from scratch.

• Reset all "Overload" States? (`reset_overload`, default: false): This option reset all "Overload" information which have been filled in the GUI. Initialize the review state allows to start a new analysis review from scratch.

• Import variant data? (`create_variant`, default: false): Variant data can be imported beside the test results. It is possible to get an overview of the tests results per variant. CARREFUL: a variant key must be defined.

• Variant key (`variant_options`): Variant key allows to name the variant according relevant variant property. Key=ECU will list all the variant and name them according the value of the field "ECU".

• Advanced options (`advanced_options`, default: false): Advanced options

• File suffix (`suff`, default: .xml): Provide the suffix of CANoe test results files.

• Consider "None" as "Passed" (`consider_none_as_passed`, default: true): By default, a test case which is stated as "none" (=without real evaluation step) are considered as "Passed".

• "Hardware revision" key (`sut_mapping_hw_rev`, default: Hardware revision): "Hardware revision" key can be found in the node of the CANoe xml results.

• "Software revision" key (`sut_mapping_sw_rev`, default: Software revision): "Software revision" key can be found in the node of the CANoe xml results.

• "Boot Loader revision" key (`sut_mapping_boot_rev`): "Boot Loader revision" key can be found in the node of the CANoe xml results.

• Add "Report File Name" to the test execution name (`displayReportFileName`, default: false): Add "Report File Name" to the test execution name.

Use this option if you want to distinguish the test execution acccording their report file name.

Adding an extra information to the name of the artefact affects the unique id of the artefact and allow to explicitely differentiate 2 test executions which have the same unique id.

• Add "Test Unit" to the test execution name (`displayTestUnit`, default: false): Add "Test Unit" to the test execution name.

Use this option if you want to distinguish the test execution acccording their Test Unit.

Adding an extra information to the name of the artefact affects the unique id of the artefact and allow to explicitely differentiate 2 test executions which have the same unique id.

• Add "Variant" to the test execution name (`displayVariant`, default: false): Add "Variant" to the test execution name.

Use this option if you want to distinguish the test execution acccording their variant.

Adding an extra information to the name of the artefact affects the unique id of the artefact and allow to explicitely differentiate 2 test executions which have the same unique id.

In addition the following options are avaiable on command line:

• `logLevel`(default: INFO): Specify the log level to be used (ALL, DEBUG, INFO, WARN, ERROR, FATAL, OFF, TRACE) the default is INFO

• `createTests`(default: YES): Shoult Test artefacts be created?

The full command line syntax for CANoe is:

``-d "type=CANoe,dir=[directory],logLevel=[text],testPath=[text],createTests=[multipleChoice],import_traceability_matrix=[booleanChoice],traceability_file=[file],reset_review=[booleanChoice],reset_overload=[booleanChoice],create_variant=[booleanChoice],variant_options=[text],advanced_options=[booleanChoice],suff=[text],consider_none_as_passed=[booleanChoice],sut_mapping_hw_rev=[text],sut_mapping_sw_rev=[text],sut_mapping_boot_rev=[text],displayReportFileName=[booleanChoice],displayTestUnit=[booleanChoice],displayVariant=[booleanChoice]"``

### Cantata

#### Description

Cantata is a Test Coverage tool. It provides an XML output file which can be imported to generate coverage metrics at function level.

For more details, refer to http://www.qa-systems.com/cantata.html.

#### Usage

Cantata has the following options:

• Cantata XML results (`xml`): Specify the path to the XML results file or directory from Cantata 6.2

• Regex Files (`regexFile`, default: .xml): Specify a regular expression to find Cantata xml files

In addition the following options are avaiable on command line:

• `logLevel`(default: INFO): Specify the log level to be used (ALL, DEBUG, INFO, WARN, ERROR, FATAL, OFF, TRACE) the default is INFO

The full command line syntax for Cantata is:

``-d "type=Cantata,xml=[file_or_directory],regexFile=[text],logLevel=[text]"``

### CheckStyle

#### Description

CheckStyle is an open source tool that verifies that Java applications adhere to certain coding standards. It produces an XML file which can be imported to generate findings.

For more details, refer to http://checkstyle.sourceforge.net/.

#### Usage

CheckStyle has the following options:

• CheckStyle results file(s) (`xml`): Point to the XML file or the directory that contains Checkstyle results. Note that the minimum supported version is Checkstyle 5.3.

• Regex Files (`regexFile`, default: .xml): Specify a regular expression to find checkstyle files

In addition the following options are avaiable on command line:

• `logLevel`(default: INFO): Specify the log level to be used (ALL, DEBUG, INFO, WARN, ERROR, FATAL, OFF, TRACE) the default is INFO

The full command line syntax for CheckStyle is:

``-d "type=CheckStyle,xml=[file_or_directory],regexFile=[text],logLevel=[text]"``

### CheckStyle (plugin)

#### Description

CheckStyle is an open source tool that verifies that Java applications adhere to certain coding standards. It produces an XML file which can be imported to generate findings.

For more details, refer to http://checkstyle.sourceforge.net/.

 This data provider requires an extra download to extract the CheckStyle binary in /addons/tools/CheckStyle_auto/. For more information, refer to the Installation and Administration Guide’s 'Third-Party Plugins and Applications' section. You may also deploy your own version of CheckStyle and make the Data Provider use it by editing /configuration/tools/CheckStyle_auto/config.tcl.

#### Usage

CheckStyle (plugin) has the following options:

• Configuration file (`configFile`): A Checkstyle configuration specifies which modules to plug in and apply to Java source files. Modules are structured in a tree whose root is the Checker module. Specify the name of the configuration file only, and the data provider will try to find it in the CheckStyle_auto folder of your custom configuration. If no custom configuration file is found, a default configuration will be used.

• Xmx (`xmx`, default: 1024m): Maximum amount of memory allocated to the java process launching Checkstyle.

• Excluded directory pattern (`excludedDirectoryPattern`): Java regular expression of directories to exclude from CheckStyle, for example: ^test|generated-sources|.*-report$or ou ^lib$

The full command line syntax for CheckStyle (plugin) is:

``-d "type=CheckStyle_auto,configFile=[text],xmx=[text],excludedDirectoryPattern=[text]"``

### CheckStyle for SQALE (plugin)

#### Description

CheckStyle is an open source tool that verifies that Java applications adhere to certain coding standards. It produces an XML file which can be imported to generate findings.

For more details, refer to http://checkstyle.sourceforge.net/.

#### Usage

CheckStyle for SQALE (plugin) has the following options:

• Configuration file (`configFile`, default: config_checkstyle_for_sqale.xml): A Checkstyle configuration specifies which modules to plug in and apply to Java source files. Modules are structured in a tree whose root is the Checker module. Specify the name of the configuration file only, and the data provider will try to find it in the CheckStyle_auto folder of your custom configuration. If no custom configuration file is found, a default configuration will be used.

• Xmx (`xmx`, default: 1024m): Maximum amount of memory allocated to the java process launching Checkstyle.

The full command line syntax for CheckStyle for SQALE (plugin) is:

``-d "type=CheckStyle_auto_for_SQALE,configFile=[text],xmx=[text]"``

### Cobertura format

#### Description

Cobertura is a free code coverage library for Java. Its XML report file can be imported to generate code coverage metrics for your Java project.

For more details, refer to http://cobertura.github.io/cobertura/.

#### Usage

Cobertura format has the following options:

• XML report (`xml`): Specify the path to the XML report generated by Cobertura (or by a tool able to produce data in this format).

In addition the following options are avaiable on command line:

• `logLevel`(default: INFO): Specify the log level to be used (ALL, DEBUG, INFO, WARN, ERROR, FATAL, OFF, TRACE) the default is INFO

The full command line syntax for Cobertura format is:

``-d "type=Cobertura,xml=[file],logLevel=[text]"``

### CodeSniffer

#### Description

CodeSniffer is a rulecker for PHP and Javascript

For more details, refer to http://www.squizlabs.com/php-codesniffer.

#### Usage

CodeSniffer has the following options:

• CodeSniffer results file (checkstyle formatted XML) (`xml`): Point to the XML file that contains CodeSniffer results.

The full command line syntax for CodeSniffer is:

``-d "type=codesniffer,xml=[file]"``

### CodeSonar

#### Description

Codesonar is a static analysis tool for C and C++ code designed for zero tolerance defect environments. It provides an XML output file which is imported to generate findings.

For more details, refer to http://www.grammatech.com/codesonar.

#### Usage

CodeSonar has the following options:

• XML results files (`xml`): Specify the path to the XML results file generated by Codesonar. The minimum version of Codesonar compatible with this data provider is 3.3.

• Regex Files (`regexFile`, default: .xml): Specify a regular expression to find CodeSonar files

In addition the following options are avaiable on command line:

• `logLevel`(default: INFO): Specify the log level to be used (ALL, DEBUG, INFO, WARN, ERROR, FATAL, OFF, TRACE) the default is INFO

The full command line syntax for CodeSonar is:

``-d "type=CodeSonar,xml=[file_or_directory],regexFile=[text],logLevel=[text]"``

### Compiler

#### Description

Compiler allows to import information from compiler logs.

#### Usage

Compiler has the following options:

• Compiler output file(s) (`txt`, mandatory): Specify the path(s) to CSV compiler log file(s). To provide multiple files click on '+'.

Each line needs to match the following format: Path;Line;Rule;Descr where Rule is one of COMP_ERR, COMPILER_WARN or COMPILER_INFO.

The full command line syntax for Compiler is:

``-d "type=Compiler,txt=[file]"``

### Configuration Checker

#### Description

Use this tool to check for duplicated files or XML Elements between a custom configuration and the standard configuration.

#### Usage

Configuration Checker has the following options:

• Standard Configuration Path (`s`):

• Custom Configurations Path (`p`):

The full command line syntax for Configuration Checker is:

``-d "type=conf-checker,s=[directory],p=[directory]"``

### Coverity

#### Description

Coverity is a static analysis tool for C, C++, Java and C#. It provides an XML output which can be imported to generate findings.

For more details, refer to http://www.coverity.com/.

#### Usage

Coverity has the following options:

• XML results file (`xml`): Specify the path to the XML file containing Coverity results.

The full command line syntax for Coverity is:

``-d "type=Coverity,xml=[file]"``

### CPD

#### Description

CPD is an open source tool which generates Copy/Paste metrics. The dectection of duplicated blocks is set to 100 tokens. CPD provides an XML file which can be imported to generate metrics as well as findings.

#### Usage

CPD has the following options:

• CPD XML results (`xml`): Specify the path to the XML results file generated by CPD. The minimum supported version is PMD/CPD 4.2.5.

The full command line syntax for CPD is:

``-d "type=CPD,xml=[file]"``

### Cppcheck

#### Description

Cppcheck is a static analysis tool for C/C++ applications. The tool provides an XML output which can be imported to generate findings.

For more details, refer to http://cppcheck.sourceforge.net/.

#### Usage

Cppcheck has the following options:

• CPPCheck XML results (`xml`): Specify the path to the XML results file or the directory from CPPCheck. Note that the minimum required version of CPPCheck for this data provider is 1.61.

• Regex Files (`regexFile`, default: .xml): Specify a regular expression to find CPPCheck files

In addition the following options are avaiable on command line:

• `logLevel`(default: INFO): Specify the log level to be used (ALL, DEBUG, INFO, WARN, ERROR, FATAL, OFF, TRACE) the default is INFO

The full command line syntax for Cppcheck is:

``-d "type=CPPCheck,xml=[file_or_directory],regexFile=[text],logLevel=[text]"``

### Cppcheck (plugin)

#### Description

Cppcheck is a static analysis tool for C/C++ applications. The tool provides an XML output which can be imported to generate findings.

For more details, refer to http://cppcheck.sourceforge.net/.

 On Windows, this data provider requires an extra download to extract the Cppcheck binary in /addons/tools/CPPCheck_auto/ and the MS Visual C++ 2010 Redistributable Package available from http://www.microsoft.com/en-in/download/details.aspx?id=5555. On Linux, you can install the cppcheck application anywhere you want. For more information, refer to the Installation and Administration Guide’s 'Third-Party Plugins and Applications' section.

#### Usage

Cppcheck (plugin) has the following options:

• Source code folder (`dir`): Specify the folder containing the source files to analyse. If you want to analyse all of source repositories specified for the project, leave this field empty.

• Ignore List (`ignores`): Specify a semi-colon-separated list of source files or source file directories to exclude from the check. For example: "lib/;folder2/". Leave this field empty to deactivate this option and analyse all files with no exception.

• Cppcheck addon (`addon`): to a Cppcheck addon. Will be passed to Cppcheck using the --addon= option.

The full command line syntax for Cppcheck (plugin) is:

``-d "type=CPPCheck_auto,dir=[directory],ignores=[text],addon=[file]"``

### CPPTest

#### Description

Parasoft C/Ctest is an integrated solution for automating a broad range of best practices proven to improve software development team productivity and software quality for C and C. The tool provides an XML output file which can be imported to generate findings and metrics.

For more details, refer to http://www.parasoft.com/product/cpptest/.

#### Usage

CPPTest has the following options:

• Directory which contains the XML results files (`results_dir`): Specify the path to the CPPTest results directory. This data provider is compatible with files exported from CPPTest version 7.2.10.34 and up.

• Results file extensions (`pattern`, default: *.xml): Specify the pattern of the results files

The full command line syntax for CPPTest is:

``-d "type=CPPTest,results_dir=[directory],pattern=[text]"``

### CPU Data Import

#### Description

CPU Data Import provides a generic import mechanism for CPU data from a CSV or Excel file.

#### Usage

CPU Data Import has the following options:

• Root node name (`root_node`, default: Resources): Specify the name of root node in the artefact tree.

• Data File (`xls_file`, mandatory): Specify the path to the file containing CPU information.

• Sheet Name (`xls_sheetname`): Specify the name of the Excel sheet that contains the CPU list.

• CPU Column name (`xls_key`): Specify the header name of the column which contains the CPU key.

• Grouping Structure (`xls_groups`): Specify the headers for Grouping Structure, separated by ";".

• Filtering (`xls_filters`): Specify the list of Header for filtering

For example: "column_name_1=regex1;column_name_2=regex2;

• Specify the CSV separator (`csv_separator`, default: ;): Specify the CSV separator

• "CPU Loop Time" Column name (`cpu_loop_column_name`, default: Total Loop Time [ms]): Specify the column name of the CPU Loop Time (Ex: "Total Loop Time [ms]")

• "Average Idle Time per loop" Column name (`cpu_idle_column_name`, default: Average idle Time per loop [ms]): Specify the column name of the Average Idle Time per loop (Ex: "Average idle Time per loop [ms]")

• "Worst Case Idle Time per loop" Column name (`cpu_worst_column_name`, default: Worse case idle Time per loop [ms]): Specify the column name of the Worst Case Idle Time per loop (Ex: "Worse case idle Time per loop [ms]")

• Create an output file (`createOutput`, default: true): Create an output file

In addition the following options are avaiable on command line:

• `logLevel`(default: INFO): Specify the log level to be used (ALL, DEBUG, INFO, WARN, ERROR, FATAL, OFF, TRACE) the default is INFO

The full command line syntax for CPU Data Import is:

``-d "type=import_cpu,root_node=[text],xls_file=[file],xls_sheetname=[text],xls_key=[text],xls_groups=[text],xls_filters=[text],csv_separator=[text],cpu_loop_column_name=[text],cpu_idle_column_name=[text],cpu_worst_column_name=[text],createOutput=[booleanChoice],logLevel=[text]"``

### CSV Coverage Import

#### Description

CSV Coverage Import provides a generic import mechanism for coverage results at function level

#### Usage

CSV Coverage Import has the following options:

• CSV file (`csv`): Enter the path to the CSV containing the coverage data.

The expected format of each line contained in the file is PATH;NAME;TESTED_C1;OBJECT_C1;TESTED_MCC;OBJECT_MCC;TESTED_MCDC;OBJECT_MCDC;TCOV_MCC;TCOV_MCDC;TCOV_C1

The full command line syntax for CSV Coverage Import is:

``-d "type=csv_coverage,csv=[file]"``

### CSV Findings

#### Description

CSV Findings is a generic tool that allows importing findings into the project.

#### Usage

CSV Findings has the following options:

• CSV File(s) (`csv`): Specify the path(s) to your CSV file(s) containing findings. To provide multiple files click on '+'. Each line in the file must use the following format and the file should include the following header:

FILE;FUNCTION;RULE_ID;MESSAGE;LINE;COL;STATUS;STATUS_MESSAGE;TOOL

The full command line syntax for CSV Findings is:

``-d "type=csv_findings,csv=[file]"``

### CSV Import

#### Description

Imports artefacts, metrics, findings, textual information and links from one or more CSV files. The expected CSV format for each of the input files is described in the user manuals in the csv_import framework reference.

 Consult [ref_csv_import] for more details about the expected CSV format.

#### Usage

CSV Import has the following options:

• CSV Separator (`separator`, default: ;): Specify the CSV Separator used in the CSV file.

• CSV Delimiter (`delimiter`, default: "): CSV Delimiter is used when the separator is used inside a cell value. If a delimiter is used as a char in a cell it has to be doubled.

The ' char is not allowed as a delimiter.

• Artefact Path Separator (`pathSeparator`, default: /): Specify the character used as a separator in an artefact's path in the input CSV file.

• Case-sensitive artefact lookup (`pathAreCaseSensitive`, default: true): When this option is turned on, artefacts in the CSV file are matched with existing source code artefacts in a case-sensitive manner.

• Ignore source file path (`ignoreSourceFilePath`, default: false): When ignoring source file path it is your responsbility to ensure that file names are unique in the project.

• Create missing files (`createMissingFile`, default: false): Automatically creates the artefacts declared in the CSV file if they do not exist.

• Ignore finding if artefact not found (`ignoreIfArtefactNotFound`, default: true): If a finding can not be attached to any artefact then it is either ignored (checked) or it is attached to the project node instead (unchecked).

• Unknown rule ID (`unknownRuleId`): this option is deprecated and will be removed in a future release. You should not use it anymore.

• Measure ID for orphan artifacts count (`orphanArteCountId`): To save the total count of orphan findings as a metric at application level, specify the ID of the measure to use in your analysis model.

• Measure ID for unknown rules count (`orphanRulesCountId`): this option is deprecated and will be removed in a future release. You should not use it anymore.

• Information ID receiving the list of unknown rules IDs (`orphanRulesListId`): this option is deprecated and will be removed in a future release. You should not use it anymore.

• CSV File (`csv`): Specify the path to the input CSV file containing artefacts, metrics, findings, textual information, links and keys.

• Metrics CSV File (`metrics`): Specify the path to the CSV file containing metrics.

• Infos CSV File (`infos`): Specify the path to the CSV file containing textual information.

• Findings CSV File (`findings`): Specify the path to the CSV file containing findings.

• Keys CSV File (`keys`): Specify the path to the CSV file containing artefact keys.

• Links CSV File (`links`): Specify the path to the CSV file containing links.

• Reports artefacts mapping problem as (`level`, default: info): When an artefact referenced in the CSV file can not be found in the project, reports the problem as an information or as a warning.

The full command line syntax for CSV Import is:

``-d "type=csv_import,separator=[text],delimiter=[text],pathSeparator=[text],pathAreCaseSensitive=[booleanChoice],ignoreSourceFilePath=[booleanChoice],createMissingFile=[booleanChoice],ignoreIfArtefactNotFound=[booleanChoice],unknownRuleId=[text],orphanArteCountId=[text],orphanRulesCountId=[text],orphanRulesListId=[text],csv=[file],metrics=[file],infos=[file],findings=[file],keys=[file],links=[file],level=[multipleChoice]"``

### CSV Tag Import

#### Description

This data provider allows setting values for attributes in the project.

#### Usage

CSV Tag Import has the following options:

• CSV file (`csv`): Specify the path to the file containing the metrics.

The full command line syntax for CSV Tag Import is:

``-d "type=csv_tag_import,csv=[file]"``

### ESLint

#### Description

ESLint is an open source tool that verifies that JavaScript applications adhere to certain coding standards. It produces an XML file which can be imported to generate findings.

For more details, refer to https://eslint.org/.

#### Usage

ESLint has the following options:

• ESLint results file (`xml`): Point to the XML file that contains ESLint results in Checkstyle format.

The full command line syntax for ESLint is:

``-d "type=ESLint,xml=[file]"``

### FindBugs-SpotBugs

#### Description

FindBugs (and its successor SpotBugs) is an open source tool that looks for bugs in Java code. It produces an XML result file which can be imported to generate findings.

For more details, refer to http://findbugs.sourceforge.net/.

#### Usage

FindBugs-SpotBugs has the following options:

• XML results file (`xml`): Specify the location of the XML file or directory containing FindBugs results. Note that the minimum supported version for FindBugs is 1.3.9, and 3.1.7 to 3.1.12 for SpotBugs.

• Regex Files (`regexFile`, default: .xml): Specify a regular expression to find FindBugs xml files

In addition the following options are avaiable on command line:

• `logLevel`(default: INFO): Specify the log level to be used (ALL, DEBUG, INFO, WARN, ERROR, FATAL, OFF, TRACE) the default is INFO

The full command line syntax for FindBugs-SpotBugs is:

``-d "type=Findbugs,xml=[file_or_directory],regexFile=[text],logLevel=[text]"``

### FindBugs-SpotBugs (plugin)

#### Description

FindBugs is an open source tool that looks for bugs in Java code. It produces an XML result file which can be imported to generate findings. Note that the data provider requires an extra download to extract the FindBugs binary in [INSTALLDIR]/addons/tools/Findbugs/. You are free to use FindBugs 3.0 or FindBugs 2.0 depending on what your standard is. For more information, refer to the Installation and Administration Manual’s "Third-Party Plugins and Applications" section.This Data Provider also supports SpotBugs (successor to FindBugs), with the same parameters. If you are using SpotBugs, its binary also has to be accessible, in [INSTALLDIR]/addons/tools/Findbugs/.

For more details, refer to http://findbugs.sourceforge.net/.

 This data provider requires an extra download to extract the FindBugs or SpotBugs binary in /addons/tools/Findbugs_auto/. In this directory, the pattern of the name of the FindBugs-SpotBugs installation directory is findbugs-${TheFindBugsVersion} or spotbugs${TheSpotBugsVersion}, for example findbugs-3.0.1 or spotbugs-4.2.2. If there are multiple installation directories, the most recent version will be chosen. If there are FindBugs or SpotBugs installation, the SpotBugs installation will be chosen. For more information, refer to the Installation and Administration Guide’s 'Third-Party Plugins and Applications' section.

#### Usage

FindBugs-SpotBugs (plugin) has the following options:

• Classes (`class_dir`, mandatory): Specify the folders and/or jar files for your project in classpath format, or point to a text file that contains one folder or jar file per line.

• Auxiliary Class path (`auxiliarypath`): Specify a list of folders and/or jars in classpath format, or specify the path to a text file that contains one folder or jar per line. This information will be passed to FindBugs or SpotBugs via the -auxclasspath parameter.

• Memory Allocation (`xmx`, default: 1024m): Maximum amount of memory allocated to the java process launching FindBugs or SpotBugs.

The full command line syntax for FindBugs-SpotBugs (plugin) is:

``-d "type=Findbugs_auto,class_dir=[file_or_directory],auxiliarypath=[file_or_directory],xmx=[text]"``

### Function Relaxer

#### Description

Function Relaxer provides a generic import mechanism for relaxing functions in source code.

#### Usage

Function Relaxer has the following options:

• CSV File (`csv`):

The full command line syntax for Function Relaxer is:

``-d "type=Function_Relaxer,csv=[file]"``

### FxCop

#### Description

FxCop is an application that analyzes managed code assemblies (code that targets the .NET Framework common language runtime) and reports information about the assemblies, such as possible design, localization, performance, and security improvements. FxCop generates an XML results file which can be imported to generate findings.

#### Usage

FxCop has the following options:

• XML results file (`xml`): Specify the XML file containing FxCop's analysis results. Note that the minimum supported version of FxCop is 1.35.

The full command line syntax for FxCop is:

``-d "type=FxCop,xml=[file]"``

### GCov

#### Description

GCov is a Code coverage program for C application. GCov generates raw text files which can be imported to generate metrics.

For more details, refer to http://gcc.gnu.org/onlinedocs/gcc/Gcov.html.

#### Usage

GCov has the following options:

• Directory containing results files (`dir`): Specify the path of the root directory containing the GCov results files.

• Results files extension (`ext`, default: *.c.gcov): Specify the file extension of GCov results files.

The full command line syntax for GCov is:

``-d "type=GCov,dir=[directory],ext=[text]"``

### Generic Findings XML Import

#### Description

Generic Findings XML Import

#### Usage

Generic Findings XML Import has the following options:

• XML File (`xml`): Specify the XML file which contains the findings results (MISRA, Coding Style…​)

• "Issue" mapping definition (`issue`):

• "Rule Id" mapping definition (`id_rule`):

• "Message" mapping definition (`message`):

• "File" mapping definition (`file`):

• "Line" mapping definition (`line`):

• "Justification" mapping definition (`justification`):

The full command line syntax for Generic Findings XML Import is:

``-d "type=findings_xml,xml=[file],issue=[text],id_rule=[text],message=[text],file=[text],line=[text],justification=[text]"``

### GNATcheck

#### Description

GNATcheck is an extensible rule-based tool that allows developers to completely define a coding standard. The results are output to a log file or an XML file that can be imported to generate findings.

#### Usage

GNATcheck has the following options:

• Log or XML file (`txt`): Specify the path to the log file or the XML file generated by the GNATcheck run.

The full command line syntax for GNATcheck is:

``-d "type=GnatCheck,txt=[file]"``

### GNATCompiler

#### Description

GNATCompiler is a free-software compiler for the Ada programming language which forms part of the GNU Compiler Collection. It supports all versions of the language, i.e. Ada 2012, Ada 2005, Ada 95 and Ada 83. It creates a log file that can be imported to generate findings.

#### Usage

GNATCompiler has the following options:

• Log file (`log`): Specify the path to the log file containing the compiler warnings.

The full command line syntax for GNATCompiler is:

``-d "type=GnatCompiler,log=[file]"``

### GNAThub

#### Description

Import data from GNAThub. GNAThub integrates and aggregates the results of AdaCore’s various static and dynamic analysis tools (GNATmetric, GNATcheck, GNATcoverage, CodePeer). Compatible with GNAT Pro versions 7.4.2 up to 18.2.

 This Data Provider will only be available after you configure your server or client config.xml with the path to your gnathub executable with a definition. Consult the Configuration Manual for more information about referencing external executables.

#### Usage

GNAThub has the following options:

• Path of the gnathub.db file (`gnatdb`): Specify the absolute path of the gnathub.db file.

The full command line syntax for GNAThub is:

``-d "type=gnathub,gnatdb=[file]"``

### Import Excel, CSV, JSON or Xml

#### Description

Import data by using a Excel, CSV, JSON or Xml file

#### Usage

Import Excel, CSV, JSON or Xml has the following options:

• Choose Excel, CSV, JSON or XML import (`import_type`, default: excel): Specify if the import is about Excel, CSV, JSON or Xml file.

• Input file (`input_file`, mandatory): Specify the Excel, CSV, JSON or Xmlinput file

• Sheetname (`sheetname`): Sheetname to read data from, required on Excel import

• Specify the CSV separator (`csv_separator`, default: ;): Specify the CSV separator, required on CSV import

• Root Element path (`root_path`): Defined the root element to retrieve the list of artifacts, required on JSON or XML import

• Log level (`logLevel`, default: INFO): Specify the log level to be used (ALL, DEBUG, INFO, WARN, ERROR, FATAL, OFF, TRACE) the default is INFO

• Artefact Type (`artefact_type`): Artefact Type used by Squore Analysis model.

Example: TEST

• Artefact Type container (`artefact_type_container`): Artefact Type container used by Squore Analysis model.

Example: TEST_FOLDER

• Artefact unique ID (`artefact_uid`): Optional unless you want to use links to these artefacts.

This is the artefact unique ID, to be used by links, from this Data Provider, or another Data Provider.Examples:

• ${ID} • T_${Name}

• ${Name}${Descr}

Note:${NAME} designates the column called NAME • Links to this artefact (`artefact_link`): Specify how to create links between this artefact and other artefacts with the following format: *<LINK_TYPE>?direction=<IN or OUT>&column=<COLUMN_NAME>&separator=<SEPARATOR>or only for xml or json files <LINK_TYPE>?direction=<IN or OUT>&array=<ARRAY_PATH_NAME>,<PATH_VALUE>*Examples: • TESTED_BY?column=Test A 'TESTED_BY' link will be created with the UID found in column 'Test' • IMPLEMENTED_BY?direction=IN&column=Implements An 'IMPLEMENTED_BY' link will be created with the UID found in column 'Implements'. Since the optional 'direction' attribute is provided, it will be set as 'IN' (default value is 'OUT') • TESTED_BY?column=Tests&separator=',' 'TESTED_BY' links will be created with all UIDs found in column 'Tests', separated by a comma • TESTED_BY?column=Tests&separator=',';REFINED_BY?column=DownLinks&separator=',' 'TESTED_BY' and 'REFINED_BY' links will be created with UIDs found in columns 'Tests' and 'DownLinks' respectively • type/inward?array=fields/issuelinks,inwardIssue/key&direction=IN 'type/inward' is the path name of link, 'fields/issuelinks' is the path array name and 'inwardIssue/key' is the path value. • SUBTASK?array=fields/subtasks,key 'SUBTASK' is the link name 'fields/subtasks' is the path array name and 'key' the value path. • Artefact name (`artefact_name`): Artefact name as displayed in Squore. Examples: •${ID}

• T_${Name} •${Name} ${Descr} Note:${NAME} designates the column or path called NAME

• Artefact keys (`artefact_keys`): Artefact keys as displayed in Squore. Examples:Id;${key} Note:${key} designates the column or path called NAME

• Path to the artefact (`path_list`): Optional. If not used, artefacts extracted from the Excel file will be directly added to the Squore root.

To specify the path in Squore of artefacts exracted from the Excel file, using the following format:

*<COLUMN_NAME>?map=[<REGEX_1>:<GROUP_NAME_1>,…​,<REGEX_N>:<GROUP_NAME_N>]&groupByDate=<YES>&format=<dd-mm-YYYY>*Examples:

• Area

Artefacts will be regrouped by the value found in the 'Area' column

• Area?map=[A*:Area A,B*:Area B]

Artefacts will be regrouped into two groups:'Area A', for all values of 'Area' column starting with letter 'A', and 'Area B' for letter 'B'.

• Started on?groupByDate=Yes&format=YYYY/mm/dd

Artefacts will be regrouped by the date found in column 'Started on', using the format 'YYYY/mm/dd'

Note:Date patterns are based on SimpleDateFormat Java class specifications.

• Textual data to extract (`info_list`): Optional.

To specify the list of textual data to extract from the Excel file, using the following format:

*<METRIC_ID>?column=<COLUMN_NAME>&map=[<REGEX_1>:<TEXT_1>,…​,<REGEX_N>:<TEXT_N>]*Examples:

• ZONE_ID?column=Zone

Textual data found in column 'Zone' will be associated to metric ZONE_ID

• ZONE_ID?column=Zone;OWNER?column=Belongs to

Textual data found in columns 'Zone' and 'Belongs to' will be associated to metric ZONE_ID and OWNER respectively

• ORIGIN?column=Comes from,map=[Cust*:External,Sub-contractor*:External,Support:Internal,Dev:Internal]

_Textual data found in column 'Comes from' will be associated to metric ORIGIN:

• With value 'External' if the column starts with 'Cust' or 'Sub-contractor'

• With value 'Internal' if the column equals 'Support' or 'Dev'

_

• Started on?groupByDate=Yes&format=YYYY/mm/dd

Artefacts will be regrouped by the date found in column 'Started on', using the format 'YYYY/mm/dd'

• Numerical metrics to extract (`metric_list`): Optional.

To specify the list of numerical data to extract from the Excel file, using the following format:

*<METRIC_ID>?column=<COLUMN_NAME>&extract=<REGEX_EXRACT>&map=[<REGEX_1>:<VALUE_1>,…​,<REGEX_N>:<VALUE_N>]*Examples:

• PRIORITY?column=Priority level

Numerical values found in column 'Priority level' will be associated to metric PRIORITY

• SEVERITY?column=Severity level,extract=S_

Numerical values found in column 'Severity level' will be associated to metric SEVERITY, after having extracted (removed) the string 'S_', because in this example, column 'Severity level' contains for example 'S_1', 'S_4', etc., and we want to obtain '1', '4', etc.

• STATUS?column=State&map=[passed:0,Passed:0,Pass:0,*nconclusive*:1,failed:2,Failed:2,FAIL:2]

_Textual values found in column 'State' will be mapped to numerical values using these rules:

• For values containing 'passed', 'Passed', 'Pass'

• For values containing 'nconclusive'

• For values containing 'failed', 'Failed, 'FAIL'

_

• Date metrics to extract (`date_list`): Optional.

To specify the list of date data to extract from the Excel file, using the following format:

*<METRIC_ID>?column=<COLUMN_NAME>&format=<DATE_FORMAT>*Examples:

• CREATION_DATE?column=Created on

Date values found in column 'Created on' will be associated to metric CREATION_DATE, using the default dd-MMM-yyyy format

• LAST_UPDATE?column=Updated on&format=yyyy/mm/dd

Date values found in column 'Created on' will be associated to metric CREATION_DATE, using the yyyy/mm/dd format

Note:Date patterns are based on SimpleDateFormat Java class specifications.

• Filters to set the list of artefacts to keep (`filter_list`): Optional.

If specified only artefacts complying with the provided filters are kept. Use the following format:

*<COLUMN_NAME>?regex=<REGEX>*Examples:

• Name?regex=^ST*

Only create artefacts for which column 'Name' starts with 'ST'

• Name?regex=^ST*;Region?regex=Europe

Same as before, but restrict to artefacts where column 'Region' is 'Europe'

• Findings (`findings_list`): Optional.

The findings generation need an operator(in, notIn,greater,grOrEq,lesser,lsOrEq) the search conditions and the values.

Examples:

R_MAPPED_STATUS?operator=notIn&conditions=[Status=[Open|Spec Validation|Estimated|Reopened]]&fValue='The status is not mapped with one of the aggregated status: open.'

• Date format (`date_format`, default: yyyy-MM-dd): Formatting the date to match the given pattern

• Import data via UID only (`import_data_via_uid_only`, default: 0): Specify this option if you want to add metric/info to an artefact which created in another Data Provider

• Header row index (`initial_row`, default: 0): Specify the line number where headers are defined.Note:Indexes start at value '0', e.g. the 4th line has index 3.

• Element Separator (`elementSeparator`, default: ;): Defined the element separator

• Concatenation delimitor (`concatSeparator`, default: ,): Defined the concatenation delimitor

The full command line syntax for Import Excel, CSV, JSON or Xml is:

``-d "type=import_generic_data,import_type=[multipleChoice],input_file=[file],sheetname=[text],csv_separator=[text],root_path=[text],logLevel=[text],artefact_type=[text],artefact_type_container=[text],artefact_uid=[text],artefact_link=[text],artefact_name=[text],artefact_keys=[text],path_list=[text],info_list=[text],metric_list=[text],date_list=[text],filter_list=[text],findings_list=[text],date_format=[text],import_data_via_uid_only=[text],initial_row=[text],elementSeparator=[text],concatSeparator=[text]"``

### JaCoCo

#### Description

JaCoCo is a free code coverage library for Java. Its XML report file can be imported to generate code coverage metrics for your Java project.

For more details, refer to http://www.eclemma.org/jacoco/.

#### Usage

JaCoCo has the following options:

• XML report (`xml`, mandatory): Specify the path to the XML report generated by JaCoCo. Note that the folder containing the XML file must also contain JaCoCo's report DTD file, available from http://www.eclemma.org/jacoco/trunk/coverage/report.dtd. XML report files are supported from version 0.6.5.

In addition the following options are avaiable on command line:

• `logLevel`(default: INFO): Specify the log level to be used (ALL, DEBUG, INFO, WARN, ERROR, FATAL, OFF, TRACE) the default is INFO

The full command line syntax for JaCoCo is:

``-d "type=Jacoco,xml=[file],logLevel=[text]"``

### Jira

#### Description

This Data Provider extracts tickets and their attributes from a Jira instance to create ticket artefacts in your project.

For more details, refer to https://www.atlassian.com/software/jira.

 The extracted JSON from Jira is then passed to the Ticket Data Import Data Provider (described in Ticket Data Import). Finer configuration of the data passed from this Data Provider to Ticket Data Import is available by editing (or overriding) /addons/tools/jira/jira_config.xml.

#### Usage

Jira has the following options:

• Jira REST API URL (`url`, mandatory): The URL used to connect to yout Jira instance's REST API URL (e.g: https://jira.domain.com/rest/api/2)

• Jira User login (`login`): Specyfy your Jira User login. The login is used in Basic authentication type.

• Jira User password (`pwd`): Specify your Jira User password. The password is used in Basic authentication type. This password can be encoded by the Jira Server so as not to be provided in readable form.

• Jira User token (`token`): Specify your Jira User token. This token is used in Bearer authentication type. If it's defined, the login/password don't need to be provided.

• JQL Request (`jql_request`): Specify a JQL request (see JIRA documentation) in order to limit the number of elements sent by the JIRA server.

For example: project=MyProject.This parameter is optional.

• Number of queried tickets (`max_results`, mandatory, default: -1): Maximum number of queried tickets returned by the query (default is -1, meaning 'retrieve all tickets').

• Additional Fields (`additional_fields`, default: environment,votes,issuelinks): List additional fields to be exported from Jira.

This field accepts a comma-separated list of field names that are added to the export request URL, for example fixVersions,versions

• Use a proxy (`useProxy`, default: false): If Squore is behind a proxy and needs to access the outside, you can configure the different properties by selecting the checkbox.

• Host name (`proxyHost`): Configure the host name (it's the same for http or https protocol). Example: http://my-company-proxy.com

• Port (`proxyPort`): Configure the port (it's the same for http or https protocol). Example: 2892

• Proxy User (`proxyUser`): Configure the user if authentication is required

• Proxy User Password (`proxyPassword`): Configure the user password if authentication is required

• Grouping Structure (`artefact_groups`, default: fields/components[0]/name): Specify the headers for Grouping Structure, separated by ";".

For example: "column_name_1=regex1;column_name_2=regex2;

• Filtering (`artefact_filters`, default: fields/issuetype/name=(Task|Bug|Improvement|New Feature)): Specify the list of Header for filtering

For example: "column_name_1=regex1;column_name_2=regex2;

• Todo list regex (`in_todo_list`, default: fields/status/name=.)*: Todo list regex (ticket which fit the regex will be considered as part of the TODO list for the analysis)

• JSON Root Path (`root_path`, default: issues): Specify the root path in the JSON file to retrieve issues.

• Ticket ID (`artefact_id`, default: id): Specify the path to the field containing the ticket ID.

• Ticket UID (`artefact_uid`, default: JR#${id}): Specify the pattern used to build the ticket Unique ID. The UID can use any information collected from the JSON file as a parameter. Example: TK#${ID}

• Ticket Name (`artefact_name`, default: ${key}): Specify the pattern used to build the name of the ticket. The name can use any information collected from the JSON file as a parameter. Example:${ID} : ${Summary} • Ticket Keys (`artefact_keys`, default: key): Specify the pattern used to find the ticket keys. The keys can use any information collected from the file, separated by ";". Example:${ID};key

• Ticket Links (`artefact_link`, default: type/inward?array=fields/issuelinks,/inwardIssue/key&direction=IN;): Specify the pattern used to find the ticket links. The links can have special syntax, see import_generic_data documentation.

• Creation Date Field (`creation_date`, default: fields/created): Enter the path to the field containing the creation date of the ticket.

For example: column_name&format="dd/mm/yyyy".

If format is not specified, the following is used by default: dd-MMM-yyyy.

• Closure Date Field (`closure_date`, default: fields/resolutiondate): Enter the path to the field containing the closure date of the ticket.

For example: column_name&format="dd/mm/yyyy".

If format is not specified, the following is used by default: dd-MMM-yyyy.

• Due Date Field (`due_date`, default: fields/duedate): Enter the path to the field containing the due date of the ticket.

For example: column_name&format="dd/mm/yyyy".

If format is not specified, the following is used by default: dd-MMM-yyyy.

• Last Updated Date Field (`last_updated_date`, default: fields/updated): Enter the path to the field containing the last updated date of the ticket.

For example: column_name&format="dd/mm/yyyy".

If format is not specified, the following is used by default: dd-MMM-yyyy.

• Time Spent (`time_spent`, default: fields/timespent): Specify the path to the field containing time spent on the issue.

• Remaining Time (`remaining_time`, default: fields/timeestimate): Specify the path to the field containing the remaining time for the issue.

• Original Time Estimate (`original_time_estimate`, default: fields/timeoriginalestimate): Specify the path to the field containing the original time estimate for the issue.

• Open Ticket Pattern (`definition_open`, default: fields/status/name=[To Do|Open|Reopened]): Specify the pattern applied to define tickets as open. This field accepts a regular expression to match one or more column headers with a list of possible values.

Example: Status=[Open|New]

• In Development Ticket Pattern (`definition_rd_progress`, default: fields/status/name=[In Progress|In Review]): Specify the pattern applied to define tickets as in development. This field accepts a regular expression to match one or more column headers with a list of possible values.

Example: Status=Implementing

• Fixed Ticket Pattern (`definition_vv_progress`, default: fields/status/name=[Verified]): Specify the pattern applied to define tickets as fixed. This field accepts a regular expression to match one or more column headers with a list of possible values.

Example: Status=Verifying;Resolution=[fixed;removed]

• Closed Ticket Pattern (`definition_close`, default: fields/status/name=[Resolved|Closed|Done]): Specify the pattern applied to define tickets as closed. This field accepts a regular expression to match one or more column headers with a list of possible values.

Example: Status=Closed

• Defect Pattern (`definition_defect`, default: fields/issuetype/name=[Bug]): Specify the pattern applied to define tickets as defects. This field accepts a regular expression to match one or more column headers with a list of possible values.

Example: Type=Bug

• Enhancement Pattern (`definition_enhancement`, default: fields/issuetype/name=[Improvement|New Feature]): Specify the pattern applied to define tickets as enhancements. This field accepts a regular expression to match one or more column headers with a list of possible values.

Example: Type=Enhancement

• Category (`category`, default: fields/components[0]/name): Specify the path to the field containing the ticket category.

• Priority (`priority`, default: fields/priority/name): Specify the path to the field containing the ticket priority.

• Severity (`severity`, default: fields/priority/name): Specify the path to the field containing severity data.

• Severity Mapping (`severity_mapping`, default: [Lowest:0,Low:1,Medium:2,High:3,Highest:4]): Specify the mapping used to associate a severity to a scale on the severity scale in the model, where 0 is least critical and 4 is most critical.

• Status (`status`, default: fields/status/name): Specify the path to the field containing the status of the ticket.

• Information Fields (`informations`, default: fields/environment;fields/votes/votes): Specify a semicolon-separated list of paths to fields you want to extract from the Jira JSON export to be added as textual information for the ticket artefacts.

For example: fields/fixVersions[0]/name;fields/versions[0]/name

• Issue URL (`issue_url`, default: ${self}/../../../../../browse/${key}): Specify the pattern used to build the ticket URL. The URL can use any information collected from the file as a parameter.

• Title (`title`, default: fields/summary): Specify the path to the field containing the title of the ticket.

• Description (`description`, default: fields/description): Specify the path to the field containing the full description of the ticket.

• Reporter (`reporter`, default: fields/reporter/displayName): Specify the path to the field containing the reporter of the ticket.

• Handler (`handler`, default: fields/assignee/displayName): Specify the path to the field containing the handler of the ticket.

In addition the following options are avaiable on command line:

• `logLevel`(default: INFO): Specify the log level to be used (ALL, DEBUG, INFO, WARN, ERROR, FATAL, OFF, TRACE) the default is INFO

The full command line syntax for Jira is:

``-d "type=jira,url=[text],login=[text],pwd=[password],token=[password],jql_request=[text],max_results=[text],additional_fields=[text],useProxy=[booleanChoice],proxyHost=[text],proxyPort=[text],proxyUser=[text],proxyPassword=[password],artefact_groups=[text],artefact_filters=[text],in_todo_list=[text],root_path=[text],artefact_id=[text],artefact_uid=[text],artefact_name=[text],artefact_keys=[text],artefact_link=[text],creation_date=[text],closure_date=[text],due_date=[text],last_updated_date=[text],time_spent=[text],remaining_time=[text],original_time_estimate=[text],definition_open=[text],definition_rd_progress=[text],definition_vv_progress=[text],definition_close=[text],definition_defect=[text],definition_enhancement=[text],category=[text],priority=[text],severity=[text],severity_mapping=[text],status=[text],informations=[text],issue_url=[text],title=[text],description=[text],reporter=[text],handler=[text],logLevel=[text]"``

### JSHint

#### Description

JSHint is an open source tool that verifies that JavaScript applications adhere to certain coding standards. It produces an XML file which can be imported to generate findings.

For more details, refer to http://jshint.com/.

#### Usage

JSHint has the following options:

• JSHint results file (Checkstyle formatted): (`xml`): Point to the XML file that contains JSHint results Checkstyle formatted.

The full command line syntax for JSHint is:

``-d "type=JSHint,xml=[file]"``

### JUnit Format

#### Description

JUnit is a simple framework to write repeatable tests. It is an instance of the xUnit architecture for unit testing frameworks. JUnit XML result files are imported as test artefacts and links to tested classes are generated in the project.

For more details, refer to http://junit.org/.

#### Usage

JUnit Format has the following options:

• Results folder (`resultDir`, mandatory): Specify the path to the folder containing the JUnit results (or by a tool able to produce data in this format). The data provider will parse subfolders recursively. Note that the minimum support version of JUnit is 4.10.

• File Pattern (`filePattern`, mandatory, default: TEST-.xml)*: Specify the pattern for files to read reports from.

• Root Artefact (`root`, mandatory, default: tests[type=TEST_FOLDER]/junit[type=TEST_FOLDER]): Specify the name and type of the artefact under which the test artefacts will be created.

In addition the following options are avaiable on command line:

• `logLevel`(default: INFO): Specify the log level to be used (ALL, DEBUG, INFO, WARN, ERROR, FATAL, OFF, TRACE) the default is INFO

The full command line syntax for JUnit Format is:

``-d "type=JUnit,resultDir=[directory],filePattern=[text],root=[text],logLevel=[text]"``

### Klocwork

#### Description

Klocwork is a static analysis tool. Its XML result file can be imported to generate findings.

For more details, refer to http://www.klocwork.com.

#### Usage

Klocwork has the following options:

• XML results file (`xml`): Specify the path to the XML results file exported from Klocwork. Note that Klocwork version 9.6.1 is the minimum required version.

The full command line syntax for Klocwork is:

``-d "type=Klocwork,xml=[file]"``

### Klocwork MISRA

#### Description

Klocwork is a static analysis tool. Its XML result file can be imported to generate findings.

For more details, refer to http://www.klocwork.com.

#### Usage

Klocwork MISRA has the following options:

• XML results file (`xml`): Specify the path to the XML results file exported from Klocwork. Note that Klocwork version 9.6.1 is the minimum required version.

The full command line syntax for Klocwork MISRA is:

``-d "type=Klocwork_misra,xml=[file]"``

### Mantis

#### Description

The Mantis Data Provider extracts tickets and their attributes from a Mantis installation and creates ticket artefacts.

Prerequisites:

• This Data Provider queries Mantis tickets using the Mantis BT REST API. An API token is required to access this API.

• The Mantis server should be configured to avoid filtering 'Authorization' headers.

For more details, refer to https://www.mantisbt.com.

 The extracted JSON from Mantis BT is then passed to the Ticket Data Import Data Provider (described in Ticket Data Import). Finer configuration of the data passed from this Data Provider to Ticket Data Import is available by editing (or overriding) /addons/tools/mantis/mantis_config.xml.

#### Usage

Mantis has the following options:

• Mantis URL (`url`, mandatory): Specify the URL of the Mantis instance (e.g: https://www.mantisbt.org/bugs/api/rest)

• Mantis API Token (`api_token`, mandatory): Copy the Mantis API Token generated from your Account Settings in Mantis.

• Number of queried tickets (`max_results`, mandatory, default: 50): Maximum number of queried tickets returned by the query (default is 50. value=-1 means 'retrieve all tickets').

• JSON Root Path (`root_path`, default: issues): Specify the root path in the JSON file to retrieve issues.

• Ticket Name (`artefact_name`, default: ${id};$Summary): Specify the pattern used to build the name of the ticket. The name can use any information collected from the CSV file as a parameter.

Example: ${ID} :${Summary}

• Grouping Structure (`artefact_groups`, default: category/name): Specify the headers for Grouping Structure, separated by ";".

For example: "column_name_1=regex1;column_name_2=regex2;

• Filtering (`artefact_filters`): Specify the list of Header for filtering

For example: "column_name_1=regex1;column_name_2=regex2;

• Issue URL (`issue_url`): Specify the pattern used to build the ticket URL. The URL can use any information collected from the CSV file as a parameter.

• Ticket UID (`artefact_uid`, default: BUG#): Specify the pattern used to build the ticket Unique ID. The UID can use any information collected from the CSV file as a parameter.

#### Usage

PMD (plugin) has the following options:

• Ruleset file (`configFile`): Specify the path to the PMD XML ruleset you want to use for this analysis. If you do not specify a ruleset, the default one from INSTALLDIR/addons/tools/PMD_auto will be used.

• Memory Allocation (`xmx`, default: 1024m): Maximum amount of memory allocated to the java process launching PMD.

The full command line syntax for PMD (plugin) is:

``-d "type=PMD_auto,configFile=[file],xmx=[text]"``

### Polyspace

#### Description

Polyspace is a static analysis tool which includes a MISRA checker. It produces an XML output which can be imported to generate findings. Polyspace Verifier detects RTE (RunTime Error) such as Division by zero, Illegal Deferencement Pointer, Out of bound array index…​ Such information is turned into statistical measures at function level. Number of Red (justified/non-justified), Number of Grey (justified/non-justified), Number of Orange (justified/non-justified), Number of Green.

#### Usage

Polyspace has the following options:

• DocBook results file (`xml`): Specify the path to the DocBook (main XML file) generated by Polyspace.

• Ignore source file path (`ignoreSourceFilePath`, default: false): Removes all path elements when doing the mapping between files in Squore project and files in the Pomyspace report. Becareful this can work only if file names in Squore project are unique.

The full command line syntax for Polyspace is:

``-d "type=Polyspace,xml=[file],ignoreSourceFilePath=[booleanChoice]"``

### pycodestyle / pep8 (plugin)

#### Description

Style Guide for Python Code. Pep8 results are imported to produce findings on Python code. This data provider requires having pycodestyle or pep8 installed on the machine running the analysis and the pycodestyle or pep8 command to be available in the path. It is compatible with pycodestyle 2.4 or pep8 1.7 and may also work with older versions.

For more details, refer to https://pypi.org/project/pycodestyle.

 Prior to using this repository connector, the path to the pycodestyle command has to be configured in the config.xml file located in the root directory of the Squore server or the Squore client: ````

#### Usage

pycodestyle / pep8 (plugin) has the following options:

• Source code directory to analyse (`dir`): Leave this field empty to analyse all sources.

The full command line syntax for pycodestyle / pep8 (plugin) is:

``-d "type=pep8_auto,dir=[directory]"``

### pylint

#### Description

Pylint is a Python source code analyzer which looks for programming errors, helps enforcing a coding standard and sniffs for some code smells (as defined in Martin Fowler’s Refactoring book). Pylint results are imported to generate findings for Python code.

For more details, refer to http://www.pylint.org/.

#### Usage

pylint has the following options:

• CSV results file (`csv`): Specify the path to the CSV file containing pylint results. Note that the minimum version supported is 1.1.0.

The full command line syntax for pylint is:

``-d "type=pylint,csv=[file]"``

### pylint (plugin)

#### Description

Coding Guide for Python Code. Pylint results are imported to produce findings on Python code. This data provider requires having pylint installed on the machine running the analysis and the pylint command to be available in the path. It is known to work with pylint 1.7.0 and may also work with older versions.

 Prior to using this repository connector, the path to the pylint command has to be configured in the config.xml file located in the root directory of the Squore server or the Squore client: ````

#### Usage

pylint (plugin) has the following options:

• Source code directory to analyse (`dir`): Leave this field empty to analyse all sources.

The full command line syntax for pylint (plugin) is:

``-d "type=pylint_auto,dir=[directory]"``

### QAC 8.2

#### Description

QA-C is a static analysis tool for MISRA checking.

#### Usage

QAC 8.2 has the following options:

• QAC output file(s) (`txt`, mandatory): Specify the path(s) to the .tab file(s) to extract findings from. To provide multiple files click on '+'

• Eliminate duplicated findings (`eliminate_duplicate`, default: false): When 2 occurences of the same finding (same rule, same file, same line, same description) is found, only one is reported.

The full command line syntax for QAC 8.2 is:

``-d "type=qac,txt=[file],eliminate_duplicate=[booleanChoice]"``

### QAC 8.2 CERT Import

#### Description

QA-C is a static analysis tool for MISRA and CERT checking.

#### Usage

QAC 8.2 CERT Import has the following options:

• QAC CERT output file(s) (`txt`, mandatory): Specify the path(s) to the .tab file(s) to extract findings from. To provide multiple files click on '+'

• Eliminate duplicated findings (`eliminate_duplicate`, default: false): When 2 occurences of the same finding (same rule, same file, same line, same description) is found, only one is reported.

The full command line syntax for QAC 8.2 CERT Import is:

``-d "type=qac_cert,txt=[file],eliminate_duplicate=[booleanChoice]"``

### Rational Logiscope

#### Description

The Logiscope suite allows the evaluation of source code quality in order to reduce maintenance cost, error correction or test effort. It can be applied to verify C, C++, Java and Ada languages and produces a CSV results file that can be imported to generate findings.

For more details, refer to http://www.kalimetrix.com/en/logiscope.

#### Usage

Rational Logiscope has the following options:

• RuleChecker results file (`csv`): Specify the path to the CSV results file from Logiscope.

The full command line syntax for Rational Logiscope is:

``-d "type=Logiscope,csv=[file]"``

### Rational Test RealTime

#### Description

Rational Test RealTime is a cross-platform solution for component testing and runtime analysis of embedded software. This Data Provider extracts coverage results, as well as tests and their status

#### Usage

Rational Test RealTime has the following options:

• .xrd folder (`logDir`): Specify the path to the folder containing the .xrd files generated by RTRT.

• Excluded file extensions (`excludedExtensions`, default: .h;.H):

• Do you want to include FE (Function and Exit) in MCDC computation? (`include_fe_in_mcdc`, default: false):

• Generate Test artefacts and structure from .xrd files? (`generateTests`, default: false):

The full command line syntax for Rational Test RealTime is:

``-d "type=RTRT,logDir=[directory],excludedExtensions=[text],include_fe_in_mcdc=[booleanChoice],generateTests=[booleanChoice]"``

### ReqIF

#### Description

RIF/ReqIF (Requirements Interchange Format) is an XML file format that can be used to exchange requirements, along with its associated metadata, between software tools from different vendors.

For more details, refer to http://www.omg.org/spec/ReqIF/.

#### Usage

ReqIF has the following options:

• Reqif Directory (`dir`): Specify the directory which contains the Reqif files

• Spec Object Type (`objType`, default: AUTO): Specify the SPEC_OBJECT_TYPE property LONG-NAME to be used to process the ReqIf file. Using the _AUTO_ value will let the Data Provider extract the value fro the ReqIf file, and assumes that there is only one such definition.

The full command line syntax for ReqIF is:

``-d "type=ReqIf,dir=[directory],objType=[text]"``

### Requirement ASIL via Excel Import

#### Description

Requirement ASIL via Excel Import

#### Usage

Requirement ASIL via Excel Import has the following options:

• Input file (`input_file`): Specify the Excel input file

• Sheetname (`sheetname`): Sheetname to read data from

• Artefact name (`artefact_name`): Artefact name as displayed in Squore. Examples:

• ${ID} • T_${Name}

• ${Name}${Descr}

Note:${NAME} designates the column called NAME • Path to the artefact (`path_list`): Optional. If not used, artefacts extracted from the Excel file will be directly added to the Squore root. To specify the path in Squore of artefacts exracted from the Excel file, using the following format: *<COLUMN_NAME>?map=[<REGEX_1>:<GROUP_NAME_1>,…​,<REGEX_N>:<GROUP_NAME_N>]&groupByDate=<YES>&format=<dd-mm-YYYY>*Examples: • Area Artefacts will be regrouped by the value found in the 'Area' column • Area?map=[A*:Area A,B*:Area B] Artefacts will be regrouped into two groups:'Area A', for all values of 'Area' column starting with letter 'A', and 'Area B' for letter 'B'. • Started on?groupByDate=Yes&format=YYYY/mm/dd Artefacts will be regrouped by the date found in column 'Started on', using the format 'YYYY/mm/dd' Note:Date patterns are based on SimpleDateFormat Java class specifications. • Textual data to extract (`info_list`): Optional. To specify the list of textual data to extract from the Excel file, using the following format: *<METRIC_ID>?column=<COLUMN_NAME>&map=[<REGEX_1>:<TEXT_1>,…​,<REGEX_N>:<TEXT_N>]*Examples: • ZONE_ID?column=Zone Textual data found in column 'Zone' will be associated to metric ZONE_ID • ZONE_ID?column=Zone;OWNER?column=Belongs to Textual data found in columns 'Zone' and 'Belongs to' will be associated to metric ZONE_ID and OWNER respectively • ORIGIN?column=Comes from,map=[Cust*:External,Sub-contractor*:External,Support:Internal,Dev:Internal] _Textual data found in column 'Comes from' will be associated to metric ORIGIN: • With value 'External' if the column starts with 'Cust' or 'Sub-contractor' • With value 'Internal' if the column equals 'Support' or 'Dev' _ • Started on?groupByDate=Yes&format=YYYY/mm/dd Artefacts will be regrouped by the date found in column 'Started on', using the format 'YYYY/mm/dd' • Numerical metrics to extract (`metric_list`): Optional. To specify the list of numerical data to extract from the Excel file, using the following format: *<METRIC_ID>?column=<COLUMN_NAME>&extract=<REGEX_EXRACT>&map=[<REGEX_1>:<VALUE_1>,…​,<REGEX_N>:<VALUE_N>]*Examples: • PRIORITY?column=Priority level Numerical values found in column 'Priority level' will be associated to metric PRIORITY • SEVERITY?column=Severity level,extract=S_ Numerical values found in column 'Severity level' will be associated to metric SEVERITY, after having extracted (removed) the string 'S_', because in this example, column 'Severity level' contains for example 'S_1', 'S_4', etc., and we want to obtain '1', '4', etc. • STATUS?column=State&map=[passed:0,Passed:0,Pass:0,*nconclusive*:1,failed:2,Failed:2,FAIL:2] _Textual values found in column 'State' will be mapped to numerical values using these rules: • For values containing 'passed', 'Passed', 'Pass' • For values containing 'nconclusive' • For values containing 'failed', 'Failed, 'FAIL' _ • Artefact unique ID (`artefact_uid`): Optional unless you want to use links to these artefacts. This is the artefact unique ID, to be used by links, from this Data Provider, or another Data Provider.Examples: •${ID}

• T_${Name} •${Name} ${Descr} Note:${NAME} designates the column called NAME

In addition the following options are avaiable on command line:

• `logLevel`(default: INFO): Specify the log level to be used (ALL, DEBUG, INFO, WARN, ERROR, FATAL, OFF, TRACE) the default is INFO

The full command line syntax for Requirement ASIL via Excel Import is:

``-d "type=import_req_asil,input_file=[file],sheetname=[text],artefact_name=[text],path_list=[text],info_list=[text],metric_list=[text],artefact_uid=[text],logLevel=[text]"``

### Requirement Data Import

#### Description

Requirement Data Import provides a generic import mechanism for requirements from a CSV.

 Requirement Data Import provides fields so you can map all your requirements and spread them over the following statuses: Proposed, Analyzed, Approved, Implemented, Verified, Postponed, Deleted, Rejected. Overlapping statuses will cause an error, but if a requirement’s status is not declared in the definition, the requirement will still be imported, and a finding will be created.

#### Usage

Requirement Data Import has the following options:

• Root Node (`root_node`, default: Requirements): Specify the name of the node to attach requirements to.

• Data File (`input_file`): Specify the path to the CSV file containing requirements.

• JSON Root Path (`root_path`): Specify the root path in the JSON file to retrieve requirements (when importing from a JSON file).

• Sheet Name (`xls_sheetname`): Specify the sheet name that contains the requirement list.

• Requirement ID (`artefact_id`): Specify the header name of the column which contains the requirement ID.

• Requirement version (`version`): Specify the header name of the column which contains the requirement version.

• Linked Requirements IDs which satisfy this requirement (`link_satisfied_by`): Specify the header name of the column which contains the requirements IDs which satisfy this requirement.

• Linked Test ID verifying this requirement (`link_tested_by`): Specify the header name of the column which contains the linked test ID verifying this requirement.

• Linked Ticket ID associated to this requirement (`link_ticket`): Specify the header name of the column which contains the linked Ticket ID corresponding to an issue or enhancement request.

• Requirement Name (`artefact_name`): Specify the pattern used to build the name of the requirement. The name can use any information collected from the CSV file as a parameter.

Example: ${ID} :${Summary}

• Requirement UID (`artefact_uid`): Specify the pattern used to build the requirement Unique ID. The UID can use any information collected from the CSV file as a parameter.

Example: TK#${ID} • Grouping Structure (`artefact_groups`): Specify the headers for Grouping Structure, separated by ";". For example: "column_name_1=regex1;column_name_2=regex2; • Filtering (`artefact_filters`): Specify the list of Header for filtering For example: "column_name_1=regex1;column_name_2=regex2; • Status (`status`, default: Status): Specify the status of requirement. • Applicable Requirement Pattern (`definition_applicable`): Specify the pattern applied to define requirements as Applicable. This field accepts a regular expression to match one or more column headers with a list of possible values. Example: Applicable=Yes • Proposed Requirement Pattern (`definition_proposed`): Specify the pattern applied to define requirements as proposed. This field accepts a regular expression to match one or more column headers with a list of possible values. Example: Status=Proposed • Analyzed Requirement Pattern (`definition_analyzed`): Specify the pattern applied to define requirements as analyzed. This field accepts a regular expression to match one or more column headers with a list of possible values. Examples: • Status=Analyzed • Status=[Analyzed|Introduced] • Status=Analyzed;Decision=[final;revised] • Approved Requirement Pattern (`definition_approved`): Specify the pattern applied to define requirements as approved. This field accepts a regular expression to match one or more column headers with a list of possible values. Example: Status=Proposed • Implemented Pattern (`definition_implemented`): Specify the pattern applied to define requirements as Implemented. This field accepts a regular expression to match one or more column headers with a list of possible values. Example: Status=Implemented • Verified Requirement Pattern (`definition_verified`): Specify the pattern applied to define requirements as Verified. This field accepts a regular expression to match one or more column headers with a list of possible values. Example: Status=Verified • Postponed Requirement Pattern (`definition_postponed`): Specify the pattern applied to define requirements as Postponed. This field accepts a regular expression to match one or more column headers with a list of possible values. Example: Status=postponed • Deleted Requirement Pattern (`definition_deleted`): Specify the pattern applied to define requirements as deleted. This field accepts a regular expression to match one or more column headers with a list of possible values. Example: Status=Deleted • Rejected Requirement Pattern (`definition_rejected`): Specify the pattern applied to define requirements as rejected. This field accepts a regular expression to match one or more column headers with a list of possible values. Example: Status=Rejected • Priority Column (`priority`): Specify the header of the column containing priority data. • 'Very high' Requirement priority Pattern (`definition_priority_very_high`): Specify the pattern applied to define requirements priority as 'Very High' (usually associated to value '1'). This field accepts a regular expression to match one or more column headers with a list of possible values. Example: Priority=1 • 'High' Requirement priority Pattern (`definition_priority_high`): Specify the pattern applied to define requirements priority as 'High' (usually associated to value '2'). This field accepts a regular expression to match one or more column headers with a list of possible values. Example: Priority=2 • 'Medium' Requirement priority Pattern (`definition_priority_medium`): Specify the pattern applied to define requirements priority as 'Medium' (usually associated to value '3'). This field accepts a regular expression to match one or more column headers with a list of possible values. Example: Priority=3 • 'Low' Requirement priority Pattern (`definition_priority_low`): Specify the pattern applied to define requirements priority as 'Low' (usually associated to value '4'). This field accepts a regular expression to match one or more column headers with a list of possible values. Example: Priority=4 • Compliance (`compliance`, default: Compliance): Specify the compliance of requirement. • 'Met' Compliance Pattern (`definition_met`): Specify the pattern applied to define requirement Compliance as 'Met'. This field accepts a regular expression to match one or more column headers with a list of possible values. Example: Compliance=Met • 'Partially Met' Compliance Pattern (`definition_partially_met`): Specify the pattern applied to define requirement Compliance as 'Partially Met'. This field accepts a regular expression to match one or more column headers with a list of possible values. Example: Compliance=Partially Met • 'Not Met' Compliance Pattern (`definition_not_met`): Specify the pattern applied to define requirement Compliance as 'Not Met'. This field accepts a regular expression to match one or more column headers with a list of possible values. Example: Compliance=Not Met • IADT (`iadt`, default: IADT Method): Specify the IADT of requirement. • 'Inspection' Test Method Pattern (`definition_inspection`): Specify the pattern applied to define requirement Test method as 'Inspection'. This field accepts a regular expression to match one or more column headers with a list of possible values. Example: IADT Method=Inspection • 'Analysis' Test Method Pattern (`definition_analysis`): Specify the pattern applied to define requirement Test method as 'Analysis'. This field accepts a regular expression to match one or more column headers with a list of possible values. Example: IADT Method=Analysis • 'Demonstration' Test Method Pattern (`definition_demonstration`): Specify the pattern applied to define requirement Test method as 'Demonstration'. This field accepts a regular expression to match one or more column headers with a list of possible values. Example: IADT Method=Demonstration • 'Test' Test Method Pattern (`definition_test`): Specify the pattern applied to define requirement Test method as 'Test'. This field accepts a regular expression to match one or more column headers with a list of possible values. Example: IADT Method=Test • Creation Date Column (`creation_date`): Enter the name of the column containing the creation date of the requirement. Accepted formats are detailed here. • Last Update Column (`last_updated`): Enter the name of the column containing the last modification date of the requirement. Accepted formats are detailed here. • URL (`url`): Specify the pattern used to build the requirement URL. The URL can use any information collected from the CSV file as a parameter. • Description Column (`description`): Specify the header of the column containing the description of the requirement. • Criticity (`criticity`, default: Criticity): Specify the criticity of requirement. • 'A' critical factor Pattern (`definition_crit_factor_A`): Specify the pattern applied to define requirement critical factor as 'A' (low). This field accepts a regular expression to match one or more column headers with a list of possible values. Example: Criticity=A. • 'B' critical factor Pattern (`definition_crit_factor_B`): Specify the pattern applied to define requirement critical factor as 'B' (medium). This field accepts a regular expression to match one or more column headers with a list of possible values. Example: Criticity=B. • 'C' critical factor Pattern (`definition_crit_factor_C`): Specify the pattern applied to define requirement critical factor as 'C' (high). This field accepts a regular expression to match one or more column headers with a list of possible values. Example: Criticity=C. • 'D' critical factor Pattern (`definition_crit_factor_D`): Specify the pattern applied to define requirement critical factor as 'D' (highest). This field accepts a regular expression to match one or more column headers with a list of possible values. Example: Criticity=D. • CSV Separator (`csv_separator`): Specify the character used in the CSV file to separate columns. • Information Fields (`informations`): Specify the list of extra textual information to import from the CSV file. This parameter expects a list of headers separated by ";" characters. For example: Company;Country;Resolution • Save Output (`createOutput`): In addition the following options are avaiable on command line: • `logLevel`(default: INFO): Specify the log level to be used (ALL, DEBUG, INFO, WARN, ERROR, FATAL, OFF, TRACE) the default is INFO The full command line syntax for Requirement Data Import is: ``-d "type=import_req,root_node=[text],input_file=[file],root_path=[text],xls_sheetname=[text],artefact_id=[text],version=[text],link_satisfied_by=[text],link_tested_by=[text],link_ticket=[text],artefact_name=[text],artefact_uid=[text],artefact_groups=[text],artefact_filters=[text],status=[text],definition_applicable=[text],definition_proposed=[text],definition_analyzed=[text],definition_approved=[text],definition_implemented=[text],definition_verified=[text],definition_postponed=[text],definition_deleted=[text],definition_rejected=[text],priority=[text],definition_priority_very_high=[text],definition_priority_high=[text],definition_priority_medium=[text],definition_priority_low=[text],compliance=[text],definition_met=[text],definition_partially_met=[text],definition_not_met=[text],iadt=[text],definition_inspection=[text],definition_analysis=[text],definition_demonstration=[text],definition_test=[text],creation_date=[text],last_updated=[text],url=[text],description=[text],criticity=[text],definition_crit_factor_A=[text],definition_crit_factor_B=[text],definition_crit_factor_C=[text],definition_crit_factor_D=[text],csv_separator=[text],informations=[text],createOutput=[booleanChoice],logLevel=[text]"`` ### SonarQube #### Description This data provider imports findings from SonarQube. Note that versions prior to 6.2 may not be supported. For more details, refer to https://www.sonarqube.org/. #### Usage SonarQube has the following options: • SonarQube Location (`sonar`, default: http://127.0.0.1:9000): Specify the URL of the SonarQube installation to work with (for example: http://localhost:9000) • SonarQube Component Key (`key`): • Version Name (`version`): • Login (`login`): • Password (`password`): The full command line syntax for SonarQube is: ``-d "type=sonarqube,sonar=[text],key=[text],version=[text],login=[text],password=[password]"`` ### SQL Code Guard #### Description SQL Code Guard is a free solution for SQL Server that provides fast and comprehensive static analysis for T-Sql code, shows code complexity and objects dependencies. For more details, refer to http://www.sqlcodeguard.com. #### Usage SQL Code Guard has the following options: • XML results (`xml`): Specify the path to the XML file containing SQL Code Guard results. The full command line syntax for SQL Code Guard is: ``-d "type=SQLCodeGuard,xml=[file]"`` ### Squore Analyzer #### Description Squore Analyzer provides basic-level analysis of your source code. For more details, refer to https://www.vector.com/squore.  The analyser can output info and warning messages in the build logs. Recent additions to those logs include better handling of structures in C code, which will produce these messages: [Analyzer] Unknown syntax declaration for function XXXXX at line yyy to indicate that we whould have found a function but, probably due to preprocessing directives, we are not able to parse it. [Analyzer] Unbalanced () blocks found in the file. Probably due to preprocessing directives, parenthesis in the file are not well balanced. [Analyzer] Unbalanced {} blocks found in the file. Probably due to preprocessing directives, curly brackets in the file are not well balanced. You can specify the languages for your source code by passing pairs of language and extensions to the `languages` parameter. Extensions are case-sensitive and cannot be used for two different languages. For example, a project mixing php and javascript files can be analysed with: ``--dp "type=SQuORE,languages=php:.php;javascript:.js,.JS"`` In order to launch an analysis using all the available languages by default, do not specify the `languages` parameter in your command line. #### Usage Squore Analyzer has the following options: • Languages (`languages`, default: ada;c;cpp;csharp;cobol;java;fortran77;fortran90;groovy;php;python;swift;vbn…​): Check the boxes for the languages used in the specified source repositories. Adjust the list of file extensions as necessary. Note that two languages cannot use the same file extension, and that the list of extensions is case-sensitive. Tip: Leave all the boxes unchecked and Squore Analyzer will auto-detect the language parser to use. • Force full analysis (`rebuild_all`, default: false): Analyses are incremental by default. Check this box if you want to force the source code parser to analyse all files instead of only the ones that have changed since the previous analysis. This is useful if you added new rule files or text parsing rules and you want to re-evaluate all files based on your modifications. • Generate control graphs (`genCG`, default: true): this option is deprecated and will be removed in a future release. You should not use it anymore. • Use qualified names (`qualified`, default: false): Note: This option cannot be modified in subsequent runs after you create the first version of your project. • Limit analysis depth (`depth`, default: false): this option is deprecated and will be removed in a future release. You should not use it anymore. • Add a 'Source Code' node (`scnode`, default: false): Using this options groups all source nodes under a common source code node instead of directly under the APPLICATION node. This is useful if other data providers group non-code artefacts like tests or requirements together under their own top-level node. This option can only be set when you create a new project and cannot be modified when creating a new version of your project. • 'Source Code' node label (`scnode_name`, default: Source Code): Specify a custom label for your main source code node. Note: this option is not modifiable. It only applies to projects where you use the "Add a 'Source Code' node" option. When left blank, it defaults to "Source Code". • Compact folders (`compact_folder`, default: true): this option is deprecated and will be removed in a future release. You should not use it anymore. • Content exclusion via regexp (`pattern`): Specify a PERL regular expression to automatically exclude files from the analysis if their contents match the regular expression. Leave this field empty to disable content-based file exclusion. • File Filtering (`files_choice`, default: Exclude): Specify a pattern and an action to take for matching file names. Leave the pattern empty to disable file filtering. • pattern (`pattern_files`): Use a shell-like wildcard e.g. '*-test.c'. • * Matches any sequence of characters in string, including a null string. • ? Matches any single character in string. • [chars] Matches any character in the set given by chars. If a sequence of the form x-y appears in chars, then any character between x and y, inclusive, will match. On Windows, this is used with the -nocase option, meaning that the end points of the range are converted to lower case first. Whereas [A-z] matches '_' when matching case-sensitively ('_' falls between the 'Z' and 'a'), with -nocase this is considered like [A-Za-z]. • \x Matches the single character x. This provides a way of avoiding the special interpretation of the characters *?[] in pattern. Tip: Use ';' to separate multiple patterns. How to specify a file: • By providing its name, containing or not a pattern • By providing its name and its path, both containing or not a pattern e.g. • *D??l?g.* : will match MyDialog.java, WinDowlog.c, …​ anywhere in the project • */[Dd]ialog/*D??l?g.* : will match src/java/Dialog/MyDialog.java, src/c/dialog/WinDowlog.c, but not src/Dlg/c/WinDowlog.c • Folder Filtering (`dir_choice`, default: Exclude): Specify a pattern and an action to take for matching folder names. Leave the pattern empty to disable folder filtering. • pattern (`pattern_dir`): Use a shell-like wildcard e.g. 'Test_*'. • * Matches any sequence of characters in string, including a null string. • ? Matches any single character in string. • [chars] Matches any character in the set given by chars. If a sequence of the form x-y appears in chars, then any character between x and y, inclusive, will match. On Windows, this is used with the -nocase option, meaning that the end points of the range are converted to lower case first. Whereas [A-z] matches '_' when matching case-sensitively ('_' falls between the 'Z' and 'a'), with -nocase this is considered like [A-Za-z]. • \x Matches the single character x. This provides a way of avoiding the special interpretation of the characters *?[] in pattern. Tip: Use ';' to separate multiple patterns. A directory can be specified: • By providing its name, containing or not a pattern • By providing its name and its path, both containing or not a pattern. In that case the full path has to match. e.g. • source? : will match directories source, sources, …​ anywhere in the project • src/tests : will not match any directory because the full path can not match • */src/tests : will match java/src/tests, native/c/src/tests, …​ To get the root path of the project it is possible to use the nodes variables ($src, $Node1, …​). Refers to "Using Data Provider Input Files From Version Control" in the Getting Started to learn more. e.g.$src/source/tests will match only the directory source/tests if it is a root directory of the project.

• Exclude files whose size exceeds (`size_limit`, default: 500000): Provide the size in bytes above which files are excluded automatically from the Squore project (Big files are usually generated files or test files). Leave this field empty to deactivate this option.

• Detect algorithmic cloning (`clAlg`, default: true): When checking this box, Squore Analyzer launches a cloning detection tool capable of finding algorithmic cloning in your code.

• Detect text cloning (`clTxt`, default: true): When checking this box, Squore Analyzer launches a cloning detection tool capable of finding text duplication in your code.

• Ignore blank lines (`clIgnBlk`, default: true): When checking this box, blanks lines are ignored when searching for text duplication

• Ignore comment blocks (`clIgnCmt`, default: true): When checking this box, blocks of comments are ignored when searching for text duplication

• Minimum size of duplicated blocks (`clRSlen`, default: 10): This threshold defines the minimum size (number of lines) of blocks that can be reported as cloned.

• Textual Cloning fault ratio (`clFR`, default: 0.1): This threshold defines how much cloning between two artefacts is necessary for them to be considered as clones by the text duplication tool. For example, a fault ratio of 0.1 means that two artefacts are considered clones if less than 10% of their contents differ.

• Algorithmic cloning fault ratio (`clAlgFR`, default: 0.1): This threshold defines how much cloning between two artefacts is necessary for them to be considered as clones by the algorithmic cloning detection tool.

• Compute Textual stability (`genTs`, default: true): this option is deprecated and will be removed in a future release. You should not use it anymore.

• Compute Algorithmic stability (`genAs`, default: true): this option is deprecated and will be removed in a future release. You should not use it anymore.

• Detect artefact renaming (`clRen`, default: true): this option is deprecated and will be removed in a future release. You should not use it anymore.

• Mark relaxed or confirmed findings as suspicious (`susp`, default: MODIFIED_BEFORE): Depending on the choosen option, relaxed findings can be flagged as suspicious in case of changes in and around the finding. In all cases, the following is to be considered:

• Only changes on effective code are considered, comments are ignored.

• Only changes inside the scope of the artefact containing the finding are considered.

• Accept Relaxation from source code comment (`relax`, default: true): Relaxing Violations in Code

Squore interprets comments formatted in one of these three ways:

• Inline Relaxation

This syntax is used to relax violations on the current line.

some code; /* %RELAX<keys> : Text to justify the relaxation */

• Relax Next Line

This syntax is used to relax a violation on the first following line that is not a comment. In the example the text of the justification will be: "Text to justify the relaxation the text of the justification continues while lines are made of comments only"

/* >RELAX<keys> : Text to justify the relaxation */

/* the text of the justification continues while */

some code;

• Block Relaxation

This syntax is used to relax violations in an entire block of code.

/* {{ RELAX<keys> : Text to justify the relaxation */

/* like for format 2 text can be on more than one line */

int my_func() {

/* contains many violations */

…​

}

/* }} RELAX<keys> */

<keys> can be one of the following:

• <*>: relax all violations

• <MNEMO>: relax violations of the rule MNEMO

• <MNEMO1,MNEMO2,…​,MNEMOn>: relax violations of rules MNEMO1 and MNEMO2 …​ and MNEMOn

It is possible to relax using a status different from derogation. In that case the keyword RELAX has to be followed by :RELAXATION_STATUS

e.g. RELAX:APPROVED if the status RELAXED_APPOVED is defined in the model.

• Additional parameters (`additional_param`): These additional parameters can be used to pass instructions to external processes started by this data provider. This value is generally left empty in most cases.

The full command line syntax for Squore Analyzer is:

``-d "type=SQuORE,languages=[multipleChoice],rebuild_all=[booleanChoice],genCG=[booleanChoice],qualified=[booleanChoice],depth=[booleanChoice],scnode=[booleanChoice],scnode_name=[text],compact_folder=[booleanChoice],pattern=[text],files_choice=[multipleChoice],pattern_files=[text],dir_choice=[multipleChoice],pattern_dir=[text],size_limit=[text],clAlg=[booleanChoice],clTxt=[booleanChoice],clIgnBlk=[booleanChoice],clIgnCmt=[booleanChoice],clRSlen=[text],clFR=[text],clAlgFR=[text],genTs=[booleanChoice],genAs=[booleanChoice],clRen=[booleanChoice],susp=[multipleChoice],relax=[booleanChoice],additional_param=[text]"``

### Squore Import

#### Description

Squore Import is a data provider used to import the results of another data provider analysis. It is generally only used for debugging purposes.

For more details, refer to support@vector.com.

#### Usage

Squore Import has the following options:

• XML folder (`inputDir`): Specify the folder that contains the squore_data_*.xml files that you want to import.

The full command line syntax for Squore Import is:

``-d "type=SQuOREImport,inputDir=[directory]"``

### Squore Virtual Project

#### Description

Squore Virtual Project is a data provider that can use the output of several projects to compile metrics in a meta-project composed of the import sub-projects.

For more details, refer to support@vector.com.

#### Usage

Squore Virtual Project has the following options:

• Paths to output.xml files (`output`): Specify the paths to all the output.xml files you want to include in the virtual project. Separate paths using ';'.

The full command line syntax for Squore Virtual Project is:

``-d "type=SQuOREVirtualProject,output=[file]"``

### Stack Data Import

#### Description

Stack Data Import provides a generic import mechanism for stack data from a CSV or Excel file.

#### Usage

Stack Data Import has the following options:

• Root node name (`root_node`, default: Resources): Specify the name of root node in the artefact tree.

• Data File (`xls_file`, mandatory): Specify the path to the file containing Stack information.

• Sheet Name (`xls_sheetname`): Specify the sheetname that contains the Stack list.

• Stack Column name (`xls_key`): Specify the header name of the column which contains the Stack key.

• Grouping Structure (`xls_groups`): Specify the headers for Grouping Structure, separated by ";".

• Filtering (`xls_filters`): Specify the list of Header for filtering

For example: "column_name_1=regex1;column_name_2=regex2;

• Specify the CSV separator (`csv_separator`, default: ;): Specify the CSV separator

• Stack size column (`stack_size_column_name`, default: Stack Size [Bytes]): Specify the name of the column of Stack Size

• Stack Average column (`stack_average_column_name`, default: Average Stack Size used [Bytes]): Specify the name of the column of Stack Average

• Stack Worst column (`stack_worst_column_name`, default: Worse Case Stack Size used [Bytes]): Specify the name of the column of Stack Worst

• Create an output file (`createOutput`, default: true): Create an output file

In addition the following options are avaiable on command line:

• `logLevel`(default: INFO): Specify the log level to be used (ALL, DEBUG, INFO, WARN, ERROR, FATAL, OFF, TRACE) the default is INFO

The full command line syntax for Stack Data Import is:

``-d "type=import_stack,root_node=[text],xls_file=[file],xls_sheetname=[text],xls_key=[text],xls_groups=[text],xls_filters=[text],csv_separator=[text],stack_size_column_name=[text],stack_average_column_name=[text],stack_worst_column_name=[text],createOutput=[booleanChoice],logLevel=[text]"``

### StyleCop

#### Description

StyleCop is a C# code analysis tool. Its XML output is imported to generate findings.

For more details, refer to https://stylecop.codeplex.com/.

#### Usage

StyleCop has the following options:

• XML results file (`xml`): Specify the path to the StyleCop XML results file. The minimum version compatible with this data provider is 4.7.

The full command line syntax for StyleCop is:

``-d "type=StyleCop,xml=[file]"``

### StyleCop (plugin)

#### Description

StyleCop is a C# code analysis tool. Its XML output is imported to generate findings.

For more details, refer to https://stylecop.codeplex.com/.

 Note that this data provider is not supported on Linux. On windows, this data provider requires an extra download to extract the StyleCop binary in /addons/tools/StyleCop_auto/ and .NET framework 3.5 to be installed on your machine (run Net.SF.StyleCopCmd.Console.exe manually once to install .NET automatically). For more information, refer to the Installation and Administration Guide’s 'Third-Party Plugins and Applications' section.

#### Usage

StyleCop (plugin) has the following options:

• Solution (`sln`): Specify the path to the .sln file to analyse. Leave empty to analyse all .sln found in the source repository.

The full command line syntax for StyleCop (plugin) is:

``-d "type=StyleCop_auto,sln=[file]"``

### Tessy

#### Description

Tessy is a tool automating module/unit testing of embedded software written in dialects of C/C++. Tessy generates an XML results file which can be imported to generate metrics. This data provider supports importing files that have a xml_version="1.0" attribute in their header.

For more details, refer to https://www.hitex.com/en/tools/tessy/.

#### Usage

Tessy has the following options:

• Results folder (`resultDir`): Specify the top folder containing XML result files from Tessy. Note that this data provider will recursively scan sub-folders looking for index.xml files to aggregate results.

The full command line syntax for Tessy is:

``-d "type=Tessy,resultDir=[directory]"``

### Test Data Import

#### Description

Test Data Import provides a generic import mechanism for tests from a CSV, Excel or JSON file. Additionnally, it generates findings when the imported tests have an unknown status or type.

 This Data Provider provides fields so you can map all your tests and spread them over the following statuses: Failed, Inconclusive, Passd. Overlapping statuses and types will cause an error, but if a test status is not declared in the definition, the test will still be imported, and a finding will be created.

#### Usage

Test Data Import has the following options:

• Root Node (`root_node`, default: Tests): Specify the name of the node to attach tests to.

• Data File (`input_file`): Specify the path to the CSV, Excel or JSON file containing tests.

• JSON Root Path (`root_path`): Specify the root path in the JSON file to retrieve tests (when importing from a JSON file).

• Excel Sheet Name (`xls_sheetname`): Specify the sheet name that contains the test list if your import file is in Excel format.

• TestID (`artefact_id`): Specify the header name of the column which contains the test ID.

• Linear Index Column (`linear_idx`): Specify the column name of the Linear Index (=Linear Index is used to order unit or integration tests in matrix graph).

• Test Name (`artefact_name`): Specify the pattern used to build the name of the test. The name can use any information collected from the CSV file as a parameter.

Example: ${ID} :${Summary}

• Test UID (`artefact_uid`): Specify the pattern used to build the test Unique ID. The UID can use any information collected from the CSV file as a parameter.

Example: TST#${ID} • Grouping Structure (`artefact_groups`): Specify the headers for Grouping Structure, separated by ";". For example: "column_name_1=regex1;column_name_2=regex2; • Filtering (`artefact_filters`): Specify the list of Header for filtering For example: "column_name_1=regex1;column_name_2=regex2; • Failed Test Pattern (`definition_failed`): Specify the pattern applied to define tests as failed. This field accepts a regular expression to match one or more column headers with a list of possible values. Example: Status=Failed • Inconcusive Test Pattern (`definition_inconclusive`): Specify the pattern applied to define tests as inconclusive. This field accepts a regular expression to match one or more column headers with a list of possible values. Example: Status=[Inconclusive|Unfinished] • Passed Test Pattern (`definition_passed`): Specify the pattern applied to define tests as passed. This field accepts a regular expression to match one or more column headers with a list of possible values. Example: Status=Passed • Status (`status`, default: status): Specify the status test. • Date when the test was executed (`execution_date`): Enter the name of the column containing the execution date of the test. Accepted formats are detailed here. • Unit of test duration (`execution_duration_unit`, default: 1): Enter the unit used for the test duration. Possible values are 's' (seconds) or 'ms' (milliseconds), default is 'ms') • Duration of the test (`execution_duration`): Enter duration of the test, in milliseconds. • TODO Pattern (`in_todo_list`): Specify the pattern applied to include tests in the TODO list. This field accepts a regular expression to match one or more column headers with a list of possible values. Example: Active=Yes • Creation Date Column (`creation_date`): Enter the name of the column containing the creation date of the test. Accepted formats are detailed here. • Last Updated Date Column (`last_updated_date`): Enter the name of the column containing the last updated date of the test. Accepted formats are detailed here. • URL (`url`): Specify the pattern used to build the test URL. The URL can use any information collected from the CSV file as a parameter. • Description Column (`description`): Specify the header of the column containing the description of the test. • Category Column (`category`): Specify the header of the column containing the category of the test. • Priority Column (`priority`): Specify the header of the column containing priority data. • CSV Separator (`csv_separator`): Specify the character used in the CSV file to separate columns. • Information Fields (`informations`): Specify the list of extra textual information to import from the CSV file. This parameter expects a list of headers separated by ";" characters. For example: Architecture;Responsible;Target • Save Output (`createOutput`): In addition the following options are avaiable on command line: • `config_file`: Specify the path to configuration file containing Test import parameters. • `logLevel`(default: INFO): Specify the log level to be used (ALL, DEBUG, INFO, WARN, ERROR, FATAL, OFF, TRACE) the default is INFO The full command line syntax for Test Data Import is: ``-d "type=import_test,config_file=[text],root_node=[text],input_file=[file],root_path=[text],xls_sheetname=[text],artefact_id=[text],linear_idx=[text],artefact_name=[text],artefact_uid=[text],artefact_groups=[text],artefact_filters=[text],definition_failed=[text],definition_inconclusive=[text],definition_passed=[text],status=[text],execution_date=[text],execution_duration_unit=[multipleChoice],execution_duration=[text],in_todo_list=[text],creation_date=[text],last_updated_date=[text],url=[text],description=[text],category=[text],priority=[text],csv_separator=[text],informations=[text],createOutput=[booleanChoice],logLevel=[text]"`` ### Test Excel Import #### Description Test Excel Import #### Usage Test Excel Import has the following options: • Input file (`input_file`): Specify the Excel input file • Sheetname (`sheetname`): Sheetname to read data from • Artefact name (`artefact_name`): Artefact name as displayed in Squore. Examples: •${ID}

• T_${Name} •${Name} ${Descr} Note:${NAME} designates the column called NAME

• Path to the artefact (`path_list`): Optional. If not used, artefacts extracted from the Excel file will be directly added to the Squore root.

To specify the path in Squore of artefacts exracted from the Excel file, using the following format:

*<COLUMN_NAME>?map=[<REGEX_1>:<GROUP_NAME_1>,…​,<REGEX_N>:<GROUP_NAME_N>]&groupByDate=<YES>&format=<dd-mm-YYYY>*Examples:

• Area

Artefacts will be regrouped by the value found in the 'Area' column

• Area?map=[A*:Area A,B*:Area B]

Artefacts will be regrouped into two groups:'Area A', for all values of 'Area' column starting with letter 'A', and 'Area B' for letter 'B'.

• Started on?groupByDate=Yes&format=YYYY/mm/dd

Artefacts will be regrouped by the date found in column 'Started on', using the format 'YYYY/mm/dd'

Note:Date patterns are based on SimpleDateFormat Java class specifications.

• Textual data to extract (`info_list`): Optional.

To specify the list of textual data to extract from the Excel file, using the following format:

*<METRIC_ID>?column=<COLUMN_NAME>&map=[<REGEX_1>:<TEXT_1>,…​,<REGEX_N>:<TEXT_N>]*Examples:

• ZONE_ID?column=Zone

Textual data found in column 'Zone' will be associated to metric ZONE_ID

• ZONE_ID?column=Zone;OWNER?column=Belongs to

Textual data found in columns 'Zone' and 'Belongs to' will be associated to metric ZONE_ID and OWNER respectively

• ORIGIN?column=Comes from,map=[Cust*:External,Sub-contractor*:External,Support:Internal,Dev:Internal]

_Textual data found in column 'Comes from' will be associated to metric ORIGIN:

• With value 'External' if the column starts with 'Cust' or 'Sub-contractor'

• With value 'Internal' if the column equals 'Support' or 'Dev'

_

• Started on?groupByDate=Yes&format=YYYY/mm/dd

Artefacts will be regrouped by the date found in column 'Started on', using the format 'YYYY/mm/dd'

• Numerical metrics to extract (`metric_list`): Optional.

To specify the list of numerical data to extract from the Excel file, using the following format:

*<METRIC_ID>?column=<COLUMN_NAME>&extract=<REGEX_EXRACT>&map=[<REGEX_1>:<VALUE_1>,…​,<REGEX_N>:<VALUE_N>]*Examples:

• PRIORITY?column=Priority level

Numerical values found in column 'Priority level' will be associated to metric PRIORITY

• SEVERITY?column=Severity level,extract=S_

Numerical values found in column 'Severity level' will be associated to metric SEVERITY, after having extracted (removed) the string 'S_', because in this example, column 'Severity level' contains for example 'S_1', 'S_4', etc., and we want to obtain '1', '4', etc.

• STATUS?column=State&map=[passed:0,Passed:0,Pass:0,*nconclusive*:1,failed:2,Failed:2,FAIL:2]

_Textual values found in column 'State' will be mapped to numerical values using these rules:

• For values containing 'passed', 'Passed', 'Pass'

• For values containing 'nconclusive'

• For values containing 'failed', 'Failed, 'FAIL'

_

• Date metrics to extract (`date_list`): Optional.

To specify the list of date data to extract from the Excel file, using the following format:

*<METRIC_ID>?column=<COLUMN_NAME>&format=<DATE_FORMAT>*Examples:

• CREATION_DATE?column=Created on

Date values found in column 'Created on' will be associated to metric CREATION_DATE, using the default dd-MMM-yyyy format

• LAST_UPDATE?column=Updated on&format=yyyy/mm/dd

Date values found in column 'Created on' will be associated to metric CREATION_DATE, using the yyyy/mm/dd format

Note:Date patterns are based on SimpleDateFormat Java class specifications.

• Filters to set the list of artefacts to keep (`filter_list`): Optional.

If specified only artefacts complying with the provided filters are kept. Use the following format:

*<COLUMN_NAME>?regex=<REGEX>*Examples:

• Name?regex=^ST*

Only create artefacts for which column 'Name' starts with 'ST'

• Name?regex=^ST*;Region?regex=Europe

Same as before, but restrict to artefacts where column 'Region' is 'Europe'

• Artefact unique ID (`artefact_uid`): Optional unless you want to use links to these artefacts.

This is the artefact unique ID, to be used by links, from this Data Provider, or another Data Provider.Examples:

• ${ID} • T_${Name}

• ${Name}${Descr}

Note:${NAME} designates the column called NAME • Links to this artefact (`artefact_link`): Specify how to create links between this artefact and other artefacts with the following format: *<LINK_TYPE>?direction=<IN OR OUT>&column=<COLUMN_NAME>&separator=<SEPARATOR>*Examples: • TESTED_BY?column=Test A 'TESTED_BY' link will be created with the UID found in column 'Test' • IMPLEMENTED_BY?direction=IN&column=Implements An 'IMPLEMENTED_BY' link will be created with the UID found in column 'Implements'. Since the optional 'direction' attribute is provided, it will be set as 'IN' (default value is 'OUT') • TESTED_BY?column=Tests&separator=',' 'TESTED_BY' links will be created with all UIDs found in column 'Tests', separated by a comma • TESTED_BY?column=Tests&separator=',';REFINED_BY?column=DownLinks&separator=',' 'TESTED_BY' and 'REFINED_BY' links will be created with UIDs found in columns 'Tests' and 'DownLinks' respectively In addition the following options are avaiable on command line: • `logLevel`(default: INFO): Specify the log level to be used (ALL, DEBUG, INFO, WARN, ERROR, FATAL, OFF, TRACE) the default is INFO The full command line syntax for Test Excel Import is: ``-d "type=import_test_excel,input_file=[file],sheetname=[text],artefact_name=[text],path_list=[text],info_list=[text],metric_list=[text],date_list=[text],filter_list=[text],artefact_uid=[text],artefact_link=[text],logLevel=[text]"`` ### Testwell CTC++ #### Description Import data from Testwell CTC++ XML results For more details, refer to http://www.testwell.fi/ctcdesc.html. #### Usage Testwell CTC++ has the following options: • Results folder (`dir`): Specify the folder containing XML test results files from Testwell CTC++. • Instrumented files extension (`extension`, default: .test.runner.c): Instrumented files extension (Extension of the instrumented files generated by ctc++) The full command line syntax for Testwell CTC++ is: ``-d "type=testwell_ctc,dir=[directory],extension=[text]"`` ### Ticket Data Import #### Description Ticket Data Import provides a generic import mechanism for tickets from a CSV, Excel or JSON file. Additionnally, it generates findings when the imported tickets have an unknown status or type.  This Data Provider provides fields so you can map all your tickets as Enhancements and defects and spread them over the following statuses: Open, In Implementation, In Verification, Closed. Overlapping statuses and types will cause an error, but if a ticket’s type or status is not declared in the definition, the ticket will still be imported, and a finding will be created. #### Usage Ticket Data Import has the following options: • Root Node (`root_node`, default: Tickets): Specify the name of the node to attach tickets to. • Data File (`input_file`): Specify the path to the CSV, Excel or JSON file containing tickets. • Excel Sheet Name (`xls_sheetname`): Specify the sheet name that contains the ticket list if your import file is in Excel format. • CSV Separator (`csv_separator`): Specify the character used in the file to separate columns. Have to be specified if the imported file is CSV type • JSON/XML Root Path (`root_path`): Specify the root path in the JSON or XML file to retrieve issues. Have to be specified if the imported file is JSON type or XML type • Ticket ID (`artefact_id`): Specify the header name or of the column or path which contains the ticket ID. • Ticket Name (`artefact_name`): Specify the pattern used to build the name of the ticket. The name can use any information collected from the file as a parameter. Example:${ID} : ${Summary} • Ticket Keys (`artefact_keys`): Specify the list of keys to import from the file. This parameter expects a list of headers or path separated by ";" characters. For example:${key};ID

• Ticket Links (`artefact_link`): Specify the pattern used to find the ticket links. The links can have special syntax, see import_generic_data documentation.

• Ticket UID (`artefact_uid`): Specify the pattern used to build the ticket Unique ID. The UID can use any information collected from the file as a parameter.

Example: TK#${ID} • Grouping Structure (`artefact_groups`): Specify the headers for Grouping Structure, separated by ";". For example: "column_name_1=regex1;column_name_2=regex2; • Filtering (`artefact_filters`): Specify the list of Header or path for filtering For example: "column_name_1=regex1;column_name_2=regex2; • Open Ticket Pattern (`definition_open`): Specify the pattern applied to define tickets as open. This field accepts a regular expression to match one or more column headers or path with a list of possible values. Example: Status=[Open|New] • In Development Ticket Pattern (`definition_rd_progress`): Specify the pattern applied to define tickets as in development. This field accepts a regular expression to match one or more column headers or path with a list of possible values. Example: Status=Implementing • Fixed Ticket Pattern (`definition_vv_progress`): Specify the pattern applied to define tickets as fixed. This field accepts a regular expression to match one or more column headers or path with a list of possible values. Example: Status=Verifying,Resolution=[fixed|removed] • Closed Ticket Pattern (`definition_close`): Specify the pattern applied to define tickets as closed. This field accepts a regular expression to match one or more column headers or path with a list of possible values. Example: Status=Closed • Defect Pattern (`definition_defect`): Specify the pattern applied to define tickets as defects. This field accepts a regular expression to match one or more column headers or path with a list of possible values. Example: Type=Bug • Enhancement Pattern (`definition_enhancement`): Specify the pattern applied to define tickets as enhancements. This field accepts a regular expression to match one or more column headers or path with a list of possible values. Example: Type=Enhancement • TODO Pattern (`in_todo_list`): Specify the pattern applied to include tickets in the TODO list. This field accepts a regular expression to match one or more column headers or path with a list of possible values. Example: Sprint=2018-23 • Creation Date Column or Path (`creation_date`): Enter the name of the column or path containing the creation date of the ticket. The date pattern can be defined here, if it isn't the same as the Date format field. For example: column_name&format="dd/mm/yyyy" or column_name&format="yyyy-MM-dd'T'hh:mm:ss'Z'". • Due Date Column or Path (`due_date`): Enter the name of the column or path containing the due date of the ticket. The date pattern can be defined here, if it isn't the same as the Date format field. For example: column_name&format="dd/mm/yyyy" or column_name&format="yyyy-MM-dd'T'hh:mm:ss'Z'". • Last Updated Date Column or Path (`last_updated_date`): Enter the name of the column or path containing the last updated date of the ticket. The date pattern can be defined here, if it isn't the same as the Date format field. For example: column_name&format="dd/mm/yyyy" or column_name&format="yyyy-MM-dd'T'hh:mm:ss'Z'". • Closure Date Column or Path (`closure_date`): Enter the name of the column or path containing the closure date of the ticket. The date pattern can be defined here, if it isn't the same as the Date format field. For example: column_name&format="dd/mm/yyyy" or column_name&format="yyyy-MM-dd'T'hh:mm:ss'Z'". • Time Spent (`time_spent`): Specify the header of the column or path containing time spent on the issue. • Remaining Time (`remaining_time`): Specify the header of the column or path containing the remaining time for the issue. • Original Time Estimate (`original_time_estimate`): Specify the header of the column or path containing the original time estimate for the issue. • Status Column or Path (`status`, default: Status): Specify the header of the column or path containing the status of the ticket. • URL (`url`): Specify the pattern used to build the ticket URL. The URL can use any information collected from the file as a parameter. • Title Column or Path (`title`): Specify the header of the column or path containing the title of the ticket. • Description Column or Path (`description`): Specify the header of the column or path containing the description of the ticket. • Category Column or Path (`category`): Specify the header of the column or path containing the category of the ticket. • Reporter Column or Path (`reporter`): Specify the header of the column or path containing the reporter of the ticket. • Handler Column or Path (`handler`): Specify the header of the column or path containing the handler of the ticket. • Priority Column or Path (`priority`): Specify the header of the column or path containing priority data. • Severity Column or Path (`severity`): Specify the header of the column or path containing severity data. • Severity Mapping (`severity_mapping`): Specify the mapping used to associate a severity to a scale on the severity scale in the model, where 0 is least critical and 4 is most critical. • Ticket Type (`type`, default: Type): The Ticket type for example defect or enhancement • Date format (`date_format`, default: yyyy-MM-dd): Formatting the date to match the given pattern. This pattern will be applied to all date fields. For example: "dd/mm/yyyy" or "yyyy-MM-dd'T'hh:mm:ss'Z'". If format is not specified, the following is used by default: dd-MMM-yyyy. • Information Fields (`informations`): Specify the list of extra textual information to import from the file. This parameter expects a list of headers separated by ";" characters. For example: Company;Country;Resolution • Save Output (`createOutput`): In addition the following options are avaiable on command line: • `logLevel`(default: INFO): Specify the log level to be used (ALL, DEBUG, INFO, WARN, ERROR, FATAL, OFF, TRACE) the default is INFO The full command line syntax for Ticket Data Import is: ``-d "type=import_ticket,root_node=[text],input_file=[file],xls_sheetname=[text],csv_separator=[text],root_path=[text],artefact_id=[text],artefact_name=[text],artefact_keys=[text],artefact_link=[text],artefact_uid=[text],artefact_groups=[text],artefact_filters=[text],definition_open=[text],definition_rd_progress=[text],definition_vv_progress=[text],definition_close=[text],definition_defect=[text],definition_enhancement=[text],in_todo_list=[text],creation_date=[text],due_date=[text],last_updated_date=[text],closure_date=[text],time_spent=[text],remaining_time=[text],original_time_estimate=[text],status=[text],url=[text],title=[text],description=[text],category=[text],reporter=[text],handler=[text],priority=[text],severity=[text],severity_mapping=[text],type=[text],date_format=[text],informations=[text],createOutput=[booleanChoice],logLevel=[text]"`` ### Vector Trace Items #### Description Import Trace Items in Vector generic format as Requirements in Squore #### Usage Vector Trace Items has the following options: • Trace Items folder (`dir`): Specify the folder containing Trace Items (Requirements) files • Trace Items file suffix (`suff`, default: .vti-tso): Provide the suffix of Trace Items (Requirements) files. • Add "Unique Id" to name (`addIdToName`, default: false): Add Unique Id to name (the unique id will be added at the end of the artefact name). This option may be mandatory in case you have requirements with the same path (ie, same name AND same location) • Add Readable ID (`addReadableId`, default: false): Add Readable ID (the readable id will be added at the beginning of the artefact name) • Planned Trace Items folder (`dirPlanned`): Specify the folder containing Planned Trace Items files. • Filter on Requirements (`filter`): The filter is a way to keep Requirements which properties match a certain pattern. Syntax:<PROPERTY_NAME>?regex=<REGEX> Examples: • No filters are provided…​ If no filters are provided, all Requirements from vTESTstudio are shown in Squore (default behavior) • Property 1?regex=V_.*…​ Only keep Requirements where 'Property 1' starts with 'V_' • Property 1?regex=V_.*;Property 2?regex=.*VALID.*…​ Only keep Requirements where 'Property 1' starts with 'V_', AND 'Property 2' contains 'VALID' • Requirements grouping (`grouping`): Grouping is a way to structure Requirements in Squore by the value of given properties, in the order they are provided. Examples:Suppose Requirements have: • an 'Origin' property ('Internal', 'External') • and a 'Criticity' property ('A', 'B', 'C, 'D') Possible values for grouping: • grouping is empty …​ If no grouping is provided, Requirement will be shown in Squore with the same structure as in vTESTstudio (default behavior) • grouping ='Origin' …​ In addition to the original structure, Requirements will be broken down by origin ('Internal, 'External', or 'Unknown' if the 'Origin' property is absent or empty) • grouping ='Origin;Criticity' …​ Same as before, but the Requirements will be broken down by Origin, THEN by Criticity ('A', 'B', 'C, 'D', or 'Unknown' if the 'Criticity' property is absent or empty) • Reset Review flags (`reset_review`, default: false): Reset Review flags is used to initialize all review flags to "false". This option can be used when the team is starting a new delivery cycle. Using this option will turn all requirements to "not reviewed". • Reset Overload flags (`reset_overload`, default: false): Reset Overload flags is used to initialize all overload flags to "default status". This option can be used when the team is starting a new delivery cycle. Using this option will imply to use the default verdicts of all requirements. In addition the following options are avaiable on command line: • `logLevel`(default: INFO): Specify the log level to be used (ALL, DEBUG, INFO, WARN, ERROR, FATAL, OFF, TRACE) the default is INFO • `default_status`(default: VERIFIED): It is possible to specify the defauls status for Requirements imported in Squore. The full command line syntax for Vector Trace Items is: ``-d "type=Vector_TraceItems,dir=[directory],suff=[text],logLevel=[text],addIdToName=[booleanChoice],addReadableId=[booleanChoice],default_status=[multipleChoice],dirPlanned=[directory],filter=[text],grouping=[text],reset_review=[booleanChoice],reset_overload=[booleanChoice]"`` ### vectorCAST #### Description The VectorCAST Data Provider extracts coverage results, as well as tests and their status For more details, refer to vectorCAST. #### Usage vectorCAST has the following options: • Retrieve the coverage data via vectorCAST API? (`generate_report`, mandatory): Squore imports vectorCAST data via "report.xml" files. The xml report file is extracted from vectorCAST API. If vectorCAST is installed on the Squore server, you can select "Yes" to ask Squore to generate the xml report file. In that case, make sure the Squore server can access to the vectorCAST results directory. If vectorCAST is not available on the Squore server, thus, you have to select "No" to import the test and coverage data via xml report files. • VectorCAST project configuration files (Path to vcm, vce or vcp) (`project_file_list`): Specify the path to your project configuration file. The path should be either: 1) Path to your project ".vcm" file 2) Path to the directory which contains all the vce or vcp (Squore will look for all reccursive folders) • Folder of vectorCAST data files (ie, vectorcast_report.xml) (`squore_report_folder`): Specify the folder which contains all the vectorCAST data files (ie, vectorcast_report.xml). The vectorcast_report.xml file is generated from vectorCAST API for squore. • Import variant data? (`create_variant`, default: false): Variant data can be imported beside the test results. It is possible to get an overview of the tests results per variant. CARREFUL: a variant key must be defined. • Variant key (`variant_options`, default: compiler;testsuite;group): Variant key allows to name the variant according relevant variant property. Key=compiler;testsuite will list all the variant and name them according the value of the field "Compiler/TestSuite". • Advanced options (`advanced_options`, default: false): • Root Artefact (`sub_root`, default: Tests): Specify the name of the artefact under which the test artefacts will be created. • Unit Tests folder (`sub_root_for_unit`, default: Unit Tests): Specify the name of the artefact under which the unit tests artefacts will be created. • System Tests folder (`sub_root_for_system`, default: System Tests): Specify the name of the artefact under which the system tests artefacts will be created. • Don’t Be "case sensitve" (`case_sensitve_option`, default: true): Don't Be "case sensitve" • Generate a testcase unique id (`create_path_unique_id`, default: false): Generate a testcase unique id based on "path + test name" This option is needed if you want to link test objects with external requirements. • VectorCAST Dir (`vectorcast_dir`): In case you want to trigger a specific version of vectorCAST, you can specify the value of the %VECTORCAST_DIR%. This is particularly useful when Squore is installed on linux. • VectorCAST version (`vectorcast_version`, default: Version 20): This option is useful when vectorcast_dir option is set. The value is the results of the following command: - %VECTORCAST_DIR%/manage -V In addition the following options are avaiable on command line: • `logLevel`(default: INFO): Specify the log level to be used (ALL, DEBUG, INFO, WARN, ERROR, FATAL, OFF, TRACE) the default is INFO The full command line syntax for vectorCAST is: ``-d "type=VectorCAST_API,logLevel=[text],generate_report=[multipleChoice],project_file_list=[file_or_directory],squore_report_folder=[file_or_directory],create_variant=[booleanChoice],variant_options=[text],advanced_options=[booleanChoice],sub_root=[text],sub_root_for_unit=[text],sub_root_for_system=[text],case_sensitve_option=[booleanChoice],create_path_unique_id=[booleanChoice],vectorcast_dir=[text],vectorcast_version=[text]"`` ### VectorCAST 2018 #### Description The VectorCAST Data Provider extracts coverage results, as well as tests and their status For more details, refer to https://www.vectorcast.com/. #### Usage VectorCAST 2018 has the following options: • HTML Report (`html_report`): Specify the path to the HTML report which contains the test results. • Source code file extension (`file_extension`, default: .c): Source code file extension • Create test artefacts from HTML report (`generateTests`, default: false): • Sub Folder for test results (`sub_root`): Sub Folder for test results. The full command line syntax for VectorCAST 2018 is: ``-d "type=VectorCAST,html_report=[file_or_directory],file_extension=[text],generateTests=[booleanChoice],sub_root=[text]"`` ### Adding More Languages to Squore Analyzer Squore Analyzer can handle files written in languages that are not officially supported with a bit of extra configuration. In this mode, only a basic analysis of the file is carried out so that an artefact is created in the project and findings can be attached to it. A subset of the base metrics from Squore Analyzer is optionally recorded for the artefact so that line counting, stability and text duplication metrics are available at file level for the new language. The example below shows how you can add TypeScript files to your analysis: 1. Copy <SQUORE_HOME>/configuration/tools/SQuORE/form.xml and its .properties files into your own configuration 2. Edit form.xml to add a new language key and associated file extensions: ``````<?xml version="1.0" encoding="UTF-8"?> <tags baseName="SQuORE" ...> <tag type="multipleChoice" key="languages" ... defaultValue="...;typescript"> ... <value key="typescript" option=".ts,.TS" /> </tag> </tags>`````` Files with extensions matching the typescript language will be added to your project as TYPESCRIPT_FILE artefacts 3. Edit the `defaultValue` of the `additional_param` field to specify how Squore Analyzer should count source code lines and comment lines in the new language, based on another language officially supported by Squore. This step is optional, and is only needed if you want the to record basic line counting metrics for the artefacts. ``````<?xml version="1.0" encoding="UTF-8"?> <tags baseName="SQuORE" ...> ... <tag type="text" key="additional_param" defaultValue="typescript=javascript" /> ... </tags>`````` Lines in TypeScript files will be counted as they would for Javascript code. 4. Add translations for the new language key to show in the web UI in Squore Analyzer’s form_en.properties ``OPT.typescript.NAME=TypeScript`` 5. Add translations for the new artefact type and new LANGUAGE information value in one of the properties files imported by your Description Bundle: ``````T.TYPESCRIPT_FILE.NAME=TypeScript File INFO_VALUE.LANGUAGE.TYPESCRIPT.NAME=Typescript INFO_VALUE.LANGUAGE.TYPESCRIPT.COLOR=#2b7489`````` 6. The new artefact type should also be declared as a type in your model. The easiest way to do this is to add it to the GENERIC_FILE alias in your analysis model, which is pre-configured to record the line counting metrics for new artefacts. You should also define a root indicator for you new artefact type. The following snippet shows a minimal configuration using a dummy indicator: ``````<!-- <configuration>/MyModel/Analysis/Bundle.xml --> <?xml version="1.0" encoding="UTF-8"?> <Bundle> ... <ArtefactType id="GENERIC_FILE" heirs="TYPESCRIPT_FILE" /> <RootIndicator artefactTypes="TYPESCRIPT_FILE" indicatorId="DUMMY" /> <Indicator indicatorId="DUMMY" scaleId="SCALE_INFO" targetArtefactTypes="TYPESCRIPT_FILE" displayTypes="IMAGE" /> <Measure measureId="DUMMY"> <Computation targetArtefactTypes="TYPESCRIPT_FILE" result="0" /> </Measure> ... </Bundle>``````  Make sure that this declaration appears in your analysis model before the inclusion of import.xml so it overrides the default analysis model. Don’t forget to add translations for your dummy indicator to avoid warnings in the Model Validator: ``````DUMMY.NAME= Generic Indicator DUMMY.DESCR= This is an indicator for additional languages in Squore Analyzer. It does not rate files in any way.`````` 7. Reload your configuration and analyse a project, checking the box for TypeScript in Squore Analyzer’s options to get Typescrypt artefacts in your project. The new option for TypeScript files in Squore Analyzer  If you are launchin an analysis from the command line, use the language key defined in step 2 to analyse TypeScript files: ``-d "type=SQuORE,languages=typescript,additional_param=typescript=javascript"`` 8. After the analysis finishes and you can see your artefacts in the tree, use the Dashboard Editor to build a dashboard for your new artefact type. 9. Finally, create a handler for the source code viewer to display your new file type into your configuration folder, by copying <SQUORE_HOME>/configuration/sources/javascript_file.properties into your own configuration as <SQUORE_HOME>/configuration/sources/typescript_file.properties. ### Advanced COBOL Parsing By default, Squore Analyzer generates artefacts for all PROGRAMs in COBOL source files. It is possible to configure the parser to also generate artefacts for all SECTIONs and PARAGRAPHs in your source code. This feature can be enabled with the following steps: 1. Open <SQUORE_HOME>/configuration/tools/SQuORE/Analyzer/artifacts/cobol/ArtifactsList.txt 2. Edit the list of artefacts to generate and add the section and paragraph types: ``````program section paragraph`````` 3. Save your changes If you create a new project, you will see the new artefacts straight away. For already-existing projects, make sure to launch a new analysis and check Squore Analyzer’s Force full analysis option to parse the entire code again and generate the new artefacts. ### Using Data Provider Input Files From Version Control Input files for Squore’s Data Providers, like source code, can be located in your version control system. When this is the case, you need to specify a variable in the input field for the Data Provider instead of an absolute path to the input file. A Data Provider using an input file extracted from a remote repository The variable to use varies depending on your scenario: • You have only one node of source code in your project In this case, the variable to use is$src.

• You have more than one node of source code in your project

In this case, you need to tell Squore in which node the input file is located. This is done using a variable that has the same name as the alias you defined for the source code node in the previous step of the wizard. For example, if your nodes are labelled Node1 and Node2 (the default names), then you can refer to them using the $Node1 and$Node2 variables.

 When using these variables from the command line on a Linux system, the $symbol must be escaped: ``-d "type=PMD,configFile=\$src/pmd_data.xml"``

## Index

### C

Configuration
Configuring the client’s work folders
Using one Squore Agent installation for multiple users
Using Java System Properties

### D

Data Providers
AntiC
AntiC
Automotive Coverage Import
Automotive Coverage Import
Automotive Tag Import
Automotive Tag Import
Axivion
Axivion
BullseyeCoverage Code Coverage Analyzer
BullseyeCoverage Code Coverage Analyzer
CANoe
CANoe
CPD
CPD
CPPTest
CPPTest
CPU Data Import
CPU Data Import
CSV Coverage Import
CSV Coverage Import
CSV Findings
CSV Findings
CSV Import
CSV Import
CSV Tag Import
CSV Tag Import
Cantata
Cantata
CheckStyle
CheckStyle
CheckStyle (plugin)
CheckStyle (plugin)
CheckStyle for SQALE (plugin)
CheckStyle for SQALE (plugin)
Cobertura format
Cobertura format
CodeSniffer
CodeSniffer
CodeSonar
CodeSonar
Compiler
Compiler
Configuration Checker
Configuration Checker
Coverity
Coverity
Cppcheck
Cppcheck
Cppcheck (plugin)
Cppcheck (plugin)
ESLint
ESLint
FindBugs-SpotBugs
FindBugs-SpotBugs
FindBugs-SpotBugs (plugin)
FindBugs-SpotBugs (plugin)
Function Relaxer
Function Relaxer
FxCop
FxCop
GCov
GCov
GNATCompiler
GNATCompiler
GNATcheck
GNATcheck
GNAThub
GNAThub
Generic Findings XML Import
Generic Findings XML Import
Import Excel
CSV
JSHint
JSHint
JUnit Format
JUnit Format
JaCoCo
JaCoCo
Jira
Jira
Klocwork
Klocwork
Klocwork MISRA
Klocwork MISRA
MISRA Rule Checking using PC-lint
MISRA Rule Checking using PC-lint
MISRA Rule Checking with QAC
MISRA Rule Checking with QAC
MSTest
MSTest
MSTest Code Coverage
MSTest Code Coverage
Mantis
Mantis
MemUsage
MemUsage
Memory Data Import
Memory Data Import
NCover
NCover
OSLC
OSLC
Oracle PLSQL compiler Warning checker
Oracle PLSQL compiler Warning checker
PC Lint MISRA 2012
PC Lint MISRA 2012
PHP Code Coverage
PHP Code Coverage
PMD
PMD
PMD (plugin)
PMD (plugin)
Polyspace
Polyspace
QAC 8.2
QAC 8.2
QAC 8.2 CERT Import
QAC 8.2 CERT Import
Rational Logiscope
Rational Logiscope
Rational Test RealTime
Rational Test RealTime
ReqIF
ReqIF
Requirement ASIL via Excel Import
Requirement ASIL via Excel Import
Requirement Data Import
Requirement Data Import
SQL Code Guard
SQL Code Guard
SonarQube
SonarQube
Squore Analyzer
Squore Analyzer
Squore Import
Squore Import
Squore Virtual Project
Squore Virtual Project
Stack Data Import
Stack Data Import
StyleCop
StyleCop
StyleCop (plugin)
StyleCop (plugin)
Tessy
Tessy
Test Data Import
Test Data Import
Test Excel Import
Test Excel Import
Testwell CTC++
Testwell CTC++
Ticket Data Import
Ticket Data Import
Vector Trace Items
Vector Trace Items
VectorCAST 2018
VectorCAST 2018
pep8
pep8
pycodestyle / pep8 (plugin)
pycodestyle / pep8 (plugin)
pylint
pylint
pylint (plugin)
pylint (plugin)
vectorCAST
vectorCAST

Java
Prerequisites

### M

Multiple Users
Using Java System Properties

### R

Repository Connectors
CVS
CVS
ClearCase
ClearCase
Folder (use GNATHub)
Folder (use GNATHub)
Folder Path
Folder Path
Git
Git
Multiple Source Nodes
Using Multiple Nodes
PTC Integrity
PTC Integrity
Perforce
Perforce
SVN
SVN
Synergy
Synergy
TFS
TFS