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/project.properties 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
|$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 project.properties contains project-wide information and should be located in the $PROJECT_HOME directory. The following properties should be defined:
|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/statics.properties 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/release1.0.properties, etc):
|version.label||name of the system version||yes|
|date.label||the date of the system version||yes|
|[any property in statics.properties]||overrides the property value specified in statics.properties||no|
Follow these guidelines when entering your data in statics.properties:
|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|
|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|
|dynamics.report=true||uncomment if you have a XRadar dynamics report and want to be able to navigate to dynamics directly from statics. (See also corresponding statics.report=true in dynamics.properties)||No|
|dynamics.root||The root of the XRadar dynamics docs root (is only valid if dynamics.report=true)||No|
|javadoc.report=true||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 javadoc.report=true)||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
|junit.report.analysis=true||uncomment if you have a junit xml report generated by standard task in ant that you want to have integrated||No|
|junit.report.file||set to the location of the junit xml report||No|
|cobertura.report.analysis=true||uncomment if you have a cobertura xml report generated by standard task in ant that you want to have integrated||No|
|cobertura.report.file||set to the location of the cobertura xml report||No|
|jcoverage.report.analysis=true||uncomment if you have a jcoverage xml report generated by standard task in ant that you want to have integrated||No|
|jcoverage.report.file||set to the location of the jcoverage xml report||No|
|source.control.report.analysis=true||uncomment if you have a source control xml report generated||No|
|source.control.report.file||set to the location of the source control xml report||No|
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).
See here for all the details on the most important part in the XRadar config.
The last thing to do is to run :
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.
ant statics_all -Dgenerate.report.only=true
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.