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.