Setting up XRadar Statics


Do the necessary installs as described in Configuration. All configurations described here has various config files placed in a similar area to the testproject. For that project all configuration can be found in the $XRADAR_HOME/testproject/ file, and various files in the $XRADAR_HOME/testproject/etc directory.

For your project, you should create a new directory with a structure similar to the one found in the testproject. I.e. the following directories should be created

Directory Contents
$PROJECT_HOME Root Directory of your project.
$PROJECT_HOME/etc Configuration directory, containing various property files.
$PROJECT_HOME/lib Directory containing additional library files, all jar files in this directory is added to the classpath.
$PROJECT_HOME/lib/$VERSION_PREFIX$VERSION Directories containing the source, class-files and (optionally) pre-generated reports. One directory for each version of the system. E.g. prefix "release" and versions 1.0, 1.5 and 2.0 would yield directories release1.0, release1.5 and release2.0


The file contains project-wide information and should be located in the $PROJECT_HOME directory. The following properties should be defined:

System Property Description Required
xradar.home Home directory of XRadar. Yes
project.home Home directory of this project. Yes
version.prefix Prefix for each version / release of your project. The prefix is used for the directories containing each version (see the directory overview above), and for naming each version-specific property file. Yes
version.current Current (latest) version of your project, e.g. 4.0. Yes
version.list Comma-separated list of versions in the project, e.g: 1.0, 2.0, 3.0, 3.5, 4.0. Yes


$YOUR_PROJECT/etc/ includes the default setup for generating statics reports. All values here can be overridden in the version-specfic property files, thus enabling different setup for different versions. When parsing these files, a property named "version" will contain the current version that is being processed.

Note that the version-specific property files are shared for statics and dynamics reports. Follow these guidelines when entering statics-related data in the version-specific property files (e.g. $YOUR_PROJECT/etc/, etc):

System Property Description Required
version.label name of the system version yes
date.label the date of the system version yes
[any property in] overrides the property value specified in no

Follow these guidelines when entering your data in

System Property Description Required
system.label name of the system Yes
target.classes the root of the unpacked class files Yes
target.source the root of the unpacked source files Yes
docs.home the directory root to create statics report Yes
Analysis Property Description Required
radar.config the path to the radar-config.xml file Yes
pmd.analysis.rulesetfiles the rulessets to run on pmd Yes
cpd.analysis.minimum.token.count the minimum token count to qualify for a duplication Yes
checkstyle.analysis.checks the checkstyle format check (set to sun as a default) Yes uncomment if you have a XRadar dynamics report and want to be able to navigate to dynamics directly from statics. (See also corresponding in No
dynamics.root The root of the XRadar dynamics docs root (is only valid if No uncomment if you have a javadoc API for your sourcefile available to integrate with the XRadar. From the package and class views, you will from here be able to browse to the relevant doc. No
javadoc.root The root of the javadoc API for the analysed source (is only valid if No
coupling.analysis=true Sets up the XRadar to run detailed class-class, class-method and method-method coupling. Gives great value for analysis, but setting the property may give long xradar processing time for large projects. No
test.suite.analysis=true Set if you have the test classes. The XRadar will find where these reference in your code base and among other things give you a direct method reference coverage clculation. The fine thing about this caclulation is that you do not need test coverage on your project to caclulate this. If you have test coverage set up (see below), this measurement will supplement and make your test analysis more complete. No
test.suite.classes This attribute is required if you have set test.suite.analysis=true. No uncomment if you have a junit xml report generated by standard task in ant that you want to have integrated No set to the location of the junit xml report No uncomment if you have a cobertura xml report generated by standard task in ant that you want to have integrated No set to the location of the cobertura xml report No uncomment if you have a jcoverage xml report generated by standard task in ant that you want to have integrated No set to the location of the jcoverage xml report No uncomment if you have a source control xml report generated No set to the location of the source control xml report No

Update $YOUR_PROJECT/build.xml

Copy the $XRADAR_HOME/build_default_project.xml to $YOUR_PROJECT/build.xml. This build file should work as is, but can of course be modified as needed for preparing / building your project (like for example the testproject/build.xml is).

Update radar-config.xml

See here for all the details on the most important part in the XRadar config.

Run ant statics_all

The last thing to do is to run :

                    ant statics_all

Depending on the project size you will now have to sit and wait and see the progress on you console.A large project (500KLOC) will typically run for about 20 minutes of analysis on a 3GHz, 1.5GB, Pentium.

Optional: You want to run a reconfiguration without having to wait for all analysis

Simply run;

                    ant statics_all

The system will reconfigure the XRadar based on new configuration and produce the report. This is especially effective if you simply want to change the radar-config.xml and see the results without having to wait for the analysis.