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.