Deploying custom checkers
| In this topic: |
To deploy a custom checker, you can do either of the following:
- Deploy the checker deployment package to the server and any build machines. You use the kwdeploy command to deploy custom checkers to the Klocwork Server, making them available to any connected desktops through synchronization.
- Deploy the package to your desktop, typically for checker testing purposes. Desktop-only deployments do not use the kwdeploy command, and are accomplished by putting the checker deployment package into the appropriate folder. KAST checkers with custom functions and C/C++ Path checkers require manual installation on the desktop because synchronization doesn’t push .dll or .so files to the desktop from the server or vice-versa.
Checker deployment packages
Deploying checkers starts with the checker deployment package. A checker deployment package is a jar or zip file archive that contains the files created when you built the custom checker. A checker deployment package contains the files required to:
- display the checker in the Configuration Editor for integration projects and in the Configuration Editor for any connected desktops, so that users can enable or disable the new checker
- detect the specific C/C++, C# or Java issue type
- display issue help for the checker in Klocwork
- display issue help for the checker in C/C++, C# or Java checker reference at http://<klocwork_server_host>:<klocwork_server_port>/documentation. Klocwork Documentation is available only if your organization has a server installation of Klocwork.
- display the appropriate message and title for the checker in the analysis results in Klocwork and the Klocwork plug-ins
When deploying a custom checker, you'll need to know whether it’s a Java, C/C++, or C# checker, and if it's a C/C++ checker, determine whether it's platform-specific. Typically, C/C++ checkers are platform-specific, however, C/C++ KAST checkers that do not use custom functions are platform-independent. Check the contents of the checker deployment package (ZIP file) to see if it contains platform subdirectories at the top level. If the package contains platform subdirectories at the top level, the checker is platform-specific. You also need to decide whether you want the checker to be disabled before deployment.
Checker deployment package contents
The contents of a checker deployment package vary depending on whether the checker is a KAST or Path checker, and also whether it is a C/C++ or Java checker. C/C++ checkers are contained in a ZIP file; Java checkers are contained in a JAR file.
The JAR for a Java Path or KAST checker contains the following files and folders:
| Filename or folder | Description |
|---|---|
| <CHECKER.CODE>.jkb | Contains the knowledge base file that defines the checker behavior for Java Path checkers only. |
| checkers.xml | Is the checker configuration, which by default has the checker enabled for analysis. This is the file you need to access if you want to disable the checker before deployment. |
| toc.xml, <CHECKER.CODE>.htm, etc. | Contains the checker’s help files converted into a format understandable by Klocwork, as well as Klocwork Documentation at http://<klocwork_server_host>:<klocwork_server_port>/documentation. |
The ZIP for a C/C++ KAST or Path checker contains the following files and folders:
| Filename or folder | Description |
|---|---|
| <CHECKER.NAME>.xml | is the checker configuration, which by default has the checker enabled for analysis. This is the file you need to access if you want to disable the checker before deployment. |
| <CHECKER.NAME>.jar | contains the checker’s help files converted into a format understandable by Klocwork, as well as Klocwork Documentation at http://<klocwork_server_host>:<klocwork_server_port>/documentation. |
| <platform directory> | the platform directory if the checker is a Path checker or is a KAST checker that uses custom functions. The platform directory should contain the plug-in library ( .so or .dll). The possible subdirectories are:
|
The ZIP for a C# KAST checker contains the following files and folders:
| Filename or folder | Description |
|---|---|
| <CHECKER.NAME>.xml | is the checker configuration, which by default has the checker enabled for analysis. This is the file you need to access if you want to disable the checker before deployment. |
| <CHECKER.NAME>.jar |
contains the checker’s help files converted into a format understandable by Klocwork, as well as Klocwork Documentation at http://<klocwork_server_host>:<klocwork_server_port>/documentation. |
Custom checker help requirements
For any checker help you create for your custom checkers, it should be in the format of a '.htm' file at the root level of your jar or zip file.
Generating help for Japanese custom checkers
If you want to create the checker in Japanese, you must perform a few additional steps to add a "/ja" folder at the root level.
Assuming you have already created your custom checker package with kwcreatechecker, you need to do the following:
- Open the folder that contains your new custom checker.
- Make a copy of the file 'help.xml' and rename it to 'help_ja.xml'. (Save it in the same directory as the original file)
- Open the newly created 'help_ja.xml' file and add 'lang="ja" to the 'help language' tag. For example:
<help language="cxx" lang="ja">
- Open Makefile in an editor and add -t help_ja.xml to the end of the kwxpack command. For example:
$(KW_INSTALL_DIR)\bin\kwxpack" MY.C.KAST.CHECKER5 checkers.xml help.xml -t help_ja.xml
- Run nmake again to generate a new custom checker zip file and ensure it includes a new '/ja' folder.