MVN Plugin
Globalyzer has a number of clients: The Workbench, the command line interface, Lite, the Ant client, and the MVN plugin. When using a MVN project, you can add code scanning with Globalyzer using our MVN plugin. It is well suited for use within automation routines and Continuous Integration (CI) systems as well as within a typical developer environment, for instance within an Integrated Development Environments (IDEs).
The Globalyzer MVN plugin generates scan reports to a directory specified the pom.xml file. Scan reports are available in a variety of formats. We ask our MVN customers to install the MVN plugin in a private MVN repository for that company.
The steps to use the Globalyzer MVN plugin are the same as any MVN plugin:
- Install the plugin
- Configure the pom.xml
- Run MVN
Contents
- 1 Install the Globalyzer MVN Plugin
- 2 Configure the Globalyzer MVN Plugin
- 3 Using Globalyzer Lite from the Command Prompt / Shell
- 4 Sharing Project Definition Files Between IDEs and Build Systems
- 5 Ease of Installation
- 6 Configuration & Rule Sets
- 7 Project Definition Format
- 8 The .globalyzerrc File
- 9 Setting Proxy Settings via Java
- 10 Exit Error Codes
- 11 Language Support
- 12 Lite vs the Globalyzer API
- 13 Lite vs the Globalyzer Workbench
Install the Globalyzer MVN Plugin
For those customers who require the MVN plugin, we make the globalyzer-mvn-plugin-x.y.z.jar file available for download. We ask that this jar file be installed in a private MVN repository at the customer's side.
Configure the Globalyzer MVN Plugin
The <build><plugins>
section of your module's pom.xml file must be configured. Here is how:
<plugin>
<groupId>com.lingoport.globalyzer.client.maven</groupId>
<artifactId>globalyzer-maven-plugin</artifactId>
<version>5.2</version>
<configuration>
<username>joe@company.com</username>
<password>joespw</password>
<ruleSetName>Java Rule Set</ruleSetName>
<serverUrl></serverUrl>
<dataDictionaryDir></dataDictionaryDir>
<projectName></projectName>
<projectDir></projectDir>
<ruleSetOwner></ruleSetOwner>
<scanName></scanName>
<scanTimeout></scanTimeout>
<filterWithDictionary></filterWithDictionary>
<reportType></reportType>
<reportPath></reportPath>
<setLog4jProperties></setLog4jProperties>
<log4jPropertiesFileDir></log4jPropertiesFileDir>
</configuration>
</plugin>
Using Globalyzer Lite from the Command Prompt / Shell
Globalyzer Lite can be executed from a command prompt or shell via the following command:
java -jar globalyzer-lite.jar some_location/YourProjectDefinitionFile.xml
After lite finishes each scan, a relevant Globalyzer report is created at the location specified in the Project Definition's report path.
Lite also allows for altering the following parameters via command line options:
- The Project Path
- The Report Path
- The Files/Directories to scan
Sharing Project Definition Files Between IDEs and Build Systems
It is common to check in a single project definition file per code repository. However, the desired IDE configuration may sometimes be incompatible with the desired build system configuration.
These incompatibilities are best solved by modifying the project definition file within the build system. The IDE config can then be used as the default.
Here is an example: The desired report type for Lite may be ScanDetailedCSV for developer usage, but will need to be ScanDetailedXML within the build system. The project definition file would then be written out with the <report-type> set to ScanDetailedCSV:
<gzproject> ... <report-type>ScanDetailedCSV</report-type> ... </gzproject>
The build system can then be set to auto-replace "ScanDetailedCSV" with "ScanDetailedXML". The following Linux command will do so:
$ sed --in-place 's|ScanDetailedCSV|ScanDetailedXML|' $WORKSPACE/ProjectDefinition.xml
If desired, the opposite replacement also may be performed at the end of the build.
Finally, here is a bash function to replace the content of any XML field:
replace_xml_token() { token_name=$1 new_content=$2 sed -ri "s|(<${token_name}>).*(</${token_name}>)|\1${new_content}\2|g" $WORKSPACE/ProjectDefinition.xml }
It may be used like so:
$ replace_xml_token "report-type" "ScanDetailedXML"
Ease of Installation
Installing Lite is easy. To install:
- Unzip the Globalyzer Lite zip file at a desired location
- Run either lite-setup.bat or lite-setup.sh depending on your system.
Configuration & Rule Sets
Before use of Globalyzer Lite, rule sets will need to be configured on the Globalyzer Server. Properly configured rule sets better detect i18n issues, and cut down the rate of false positives.
A Project Definition File will then need to be created for the given project. This file may be distributed to multiple users working on the same project.
The project definition file will need to make use of the correct rule sets relevant to the project, and to specify which directories to scan with each rule set. It is recommended that this file be configured by an i18n knowledgeable developer or i18n specialist.
Project Definition Format
Here is the template for a project definition file. For the full instructions to setup a project definition file, see our help page.
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <!-- All items should be allowed anywhere in the xml as long as the hierarchy is preserved --> <gzproject> <login> <username></username> <password></password> <server></server> <!-- Optional Parameters --> <optional> <proxy-user></proxy-user> <proxy-password></proxy-password> <proxy-host></proxy-host> <proxy-port></proxy-port> <optional> </login> <project-path></project-path> <!-- May instead be specified from command line --> <project-name></project-name> <report-path></report-path> <!-- May instead be specified from command line --> <report-type></report-type> <scans> <scan> <!-- create and execute a single scan with this info --> <scan-name></scan-name> <ruleset-name></ruleset-name> <ruleset-owner></ruleset-owner> </scan> <scan> <!-- create and execute a single scan with this info --> <scan-name></scan-name> <ruleset-name></ruleset-name> <ruleset-owner></ruleset-owner> <!-- optional: specify files/directories to scan --> <scan-items> <item></item> <item></item> </scan-items> </scan> </scans> </gzproject>
The .globalyzerrc File
Globalyzer Lite supports an optional .globalyzerrc file. This file may be used to specify login, server, and proxy parameters. Below is an example .globalyzerrc file. It contains all parameters that may be set within the rc file:
server https://www.globalyzer.com/gzserver username user@company.com password aPasswordHere proxy-host https://internalhost.company.com proxy-port 81038 proxy-user ExampleUser proxy-password ExamplePassword
All settings besides 'server' are optional. And project definition files do not need to specify parameters set in the rc file (with one exception). Any parameter that is set in the project definition file will override the rc file setting.
If you choose to use a .globalyzerrc, the 'server' parameter is mandatory. It must match the server specified in project definition files. This helps prevent rule sets from being retrieved from the wrong server.
Setting Proxy Settings via Java
If you prefer to specify proxy settings via Java, rather than through the project definition file, you may use any of the following Java settings.
-Dhttp.proxyHost=your.server.com -Dhttp.proxyPort=80 -Dhttps.proxyHost=your.server.com -Dhttps.proxyPort=80 -Dhttp.nonProxyHosts=123.210.123.210 -DsocksProxyHost=your.server.com -DsocksProxyPort=1080
More info at: https://docs.oracle.com/javase/7/docs/technotes/guides/net/proxies.html
Exit Error Codes
Type | |
---|---|
Name | Exit Code |
Normal | |
EXIT_NORMAL | 0 |
XML Issues | |
NO_PATH_TO_XML_FILE | 10 |
DUPLICATE_PARAMETER_IN_XML | 11 |
XML_PARAMETER_BLANK | 12 |
XML_INVALID_PARAMETER | 13 |
UNABLE_TO_READ_SCHEMA | 14 |
Globalyzer API compatibility | |
GLOBALYZER_API_REPORT_TYPE_NOT_MATCHED | 30 |
GLOBALYZER_API_EXCEPTION | 31 |
Input issues | |
IMPROPER_INPUT | 51 |
INVALID_COMMANDS | 52 |
PROJECT_PATH_DOES_NOT_EXIST | 53 |
Output Issues | |
SCAN_FAILED | 60 |
Language Support
Globalyzer Lite supports the same languages as the full Globalyzer product. It allows users to scan a number of source code in different programming languages:
- ActionScript,
- C#,
- C/C++ (many variations),
- Delphi,
- HTML (in various web files),
- Java,
- JavaScript, (includes AngularJS, NodeJS, and other libraries)
- Objective-C,
- MXML,
- Perl,
- PHP,
- Qt,
- SQL (Oracle, MS SQL, MySQL, PostgreSQL),
- Visual Basic (Classic, .NET),
- VBScript, and
- XML
Lite vs the Globalyzer API
Globalyzer Lite utilizes the Globalyzer API. Using the API directly is more powerful, but also requires writing a custom java application.
Lite vs the Globalyzer Workbench
In comparison to the Globalyzer Workbench, Globalyzer Lite is smaller, faster to install and does not require a database. Lite supports direct integration with IDEs, while the Workbench is its own standalone program. Additionally, unlike the workbench, multiple instances of Lite may be run concurrently. This allows Continuous Integration systems to use Lite to provision the scanning of multiple projects.