As part of Structure101 it is possible to check for detrimental XS changes prior to publishing, and if XS is found to be increasing, an exception can be raised to break the build and hence abort the publish to the repository.
The check-xs operation is most likely to be useful when you wish to enforce KALOI (keep a lid on it) in a continuous build environment. KALOI promotes the idea that where a codebase has XS (or not) it is undesirable for items with XS to increase, or to be introduced, even if that codebase has a large accumulative XS value to begin with.
Example XML file to perform the operation:
<?xml version="1.0" encoding="UTF-8"?>
<headless version="1.0">
<operations>
<operation type="check-xs">
<argument name="output-file" value="c:/abc/xs-offenders.xml"/>
<argument name="output-dir" value="const(THIS_FILE)/ide-data"/>
<argument name="baseline" value="1.0.0"/>
<argument name="fail-on-offenders" value="false"/>
<argument name="identifier-on-offender" value="Structure101 new XS offender found"/>
</operation>
</operations>
<arguments>
<argument name="local-project" value="C:\Documents and Settings\user\project.java.hsp">
<override attribute="classpath" value="C:\classes-to-parse"/>
</argument>
<argument name="repository" value="C:\repository"/>
<argument name="project" value="project"/>
</arguments>
</headless>
Available arguments include:
Argument | Required | Description |
---|---|---|
repository | yes | The path to the Structure101 Studio repository root directory, e.g. c:/repository, /home/usr/x/repository, or, if remote, http://<servernameorip><:portno>/s101j/data. |
project | yes | The name of the project in the repository to compare against. |
local-project | yes | See project-spec. |
output-file | no | File to which XS offenders are recorded. Stored in XML format. This can be a relative or absolute path. |
output-dir | no | Path to directory of output-file. This option is retained for backward compatibility purposes. |
baseline | no | Optionally specify which snapshot-label to compare against (i.e. the XS offenders persisted for that snapshot). |
fail-on-offenders | no | If set to true then a runtime exception will be thrown if any offenders are found. Default value is true. |
identifier-on-offender | no | If set then the text will be present in console output if an offender is found. This feature can be used in conjunction with Hudson or Jenkins (Textfinder plugin) to set the build status unstable or failed. |
verbose | no | If set to true then the detected offenders will be output to the console. |
detailed | no | If set to true, then the list of XS offenders at the method level will be saved to output. If false only higher level XS offenders are included, e.g. class and package. Default value is false. |
use-xs-from-repository | no | The XS configuration stored in the referenced repository will be used instead of the default to determine XS offenders. |
use-xs-configuration-file | no | The XML configuration file containing your custom XS configuration. See XS Configuration in Structure101 Studio for when you wish to deviate from the standard XS thresholds. |
use-xs-configuration | no | The name of the XS configuration to use e.g "My Structural XS". |
Important: Requires a valid license file in the current directory with a build license, or the -licensedirectory parameter to be set.