As a project grows, it is increasingly difficult to spot what has changed from one day to the other. This report helps the developers in finding out the changes (up/down) over a specific time window. It then becomes a habit for the developers to correct any "up" movements (increase in the number of violations/errors).
The movers reports show what has changed in a given time window. This gives an opportunity to the developers to see the impact of their latest changes; this is especially useful if you have a large project with a "constant" number of violations. Day in, day out, you expect about 100 violations for instance, if it goes to 110 you want to know why and what is responsible for it.
Here is the ant call, we have not described how or where you generate the qalab.xml file:
<taskdef name="QALabMover" classname="net.objectlab.qalab.ant.BuildStatMoverTask"> <classpath> <pathelement location="${lib}/qalab-1.0.jar" /> <pathelement location="${lib}/xercesImpl-2.6.2.jar" /> <pathelement location="${lib}/jcommon-1.0.5.jar" /> <pathelement location="${lib}/jfreechart-1.0.2.jar" /> <pathelement location="${lib}/log4j.jar" /> </classpath> </taskdef> <QALabMover inputFile="qalab.xml" types="checkstyle,pmd" startTimeHoursOffset="50" weekendAdjustment="true" quiet="true" outputXMLfile="qalab-mover.xml"/>
Parameter | Mandatory | Description |
---|---|---|
inputFile | Yes | The input file, in this case the qalab.xml, the consolidated statistics file. |
outputXMLfile | Yes | The output xml that will contain the up and down values. |
types | Yes | any combination of 'checkstyle','pmd','pmd-cpd','simian','findbugs','cobertura-branch','cobertura-line' comma-separated. The chart will contain one serie (line) for each style; eg 'checkstyle' will only display checkstyle. 'checkstyle,pmd' will display both checkstyle and pmd. |
startTimeHoursOffset | No | number of hours to go back in time from "now" to find the start date and time of the time window.
This is assumed to run during a build and the time window would be 50 hours from now for instance. |
weekendAdjustment | No | if 'yes' or 'true', if the startTime falls on a weekend, the startTime will be adjusted by a further 48 hours.
The reason being is that a build probably does not run (with changes) over the weekend, so it is
unlikely that there would be changes. The time window specify what you'd like to consider as "latest" changes. If we say 48h, then the movers on a Monday night will be considered between the Saturday night and the Monday night. Unless the team works during weekends, there should not be any move and the time window is therefore "lost", you'd like 48h of "work time"; hence the introduction of the adjust for weekend, if it is true and the start of the window falls on a weekend (Monday going back to Saturday), then it subtracts a further 48h. so it is Thursday evening to Monday evening. |
startTimeWindow | No | Rather than using startTimeHoursOffset and weekendAdjustment, one can define a precise time window for the stats to take into account. This is done by using startTimeWindow (yyyy-mm-dd HH:MM:ss) and endTimeWindow (optional) |
endTimeWindow | No | see above (yyyy-mm-dd HH:MM:ss) |
hoursOffsetForLastRun | No, default 24h | New parameter since 0.9.1, if you set the setHoursOffsetForLastRun to 0, QALab will expect an EXACT match of the endTimeWindow for the last statistics, if there is no such a stat, it will deduct that the value is now 0. Otherwise it will decide whether it fell down to 0 or not by looking over the last 24h (and if there is no stat, it will assume that it fell to 0). This parameter may be useful for people who create multiple qalab stats for a day. |
quiet | No | (default true), if false logs debug information on the console. |
Here is the basic structure of the output:
<?xml version='1.0' encoding='UTF-8'?> <moversreport> <types>type1,type2</type> <datethreshold>yyyy-mm-dd HH:MM:ss</datethreshold> <daterun>yyyy-mm-dd HH:MM:ss</daterun> <up> <file name="A.java"> <diff previousrun="yyyy-mm-dd HH:MM:ss" currentrun="yyyy-mm-dd HH:MM:ss" type="type1" previouserrors="n" currenterrors="i" diff="i-n"/> <diff previousrun="yyyy-mm-dd HH:MM:ss" currentrun="yyyy-mm-dd HH:MM:ss" type="type2" previouserrors="n" currenterrors="i" diff="i-n"/> ... </file> <file ... ... </up> <down> <file name="B.java"> <diff previousrun="yyyy-mm-dd HH:MM:ss" currentrun="yyyy-mm-dd HH:MM:ss" type="type2" previouserrors="n" currenterrors="i" diff="i-n"/> ... </file> <file ... ... </down> </moversreport>
And here is a filled example:
<?xml version='1.0' encoding='UTF-8'?> <moversreport> <types>checkstyle,pmd,findbugs</types> <datethreshold>2005-06-16 11:24:14</datethreshold> <daterun>2005-06-20 13:24:15</daterun> <up> <file name="net/objectlab/qalab/ant/AntTaskLogger.java"> <diff previousrun="-" currentrun="2005-06-17 11:42:03" type="checkstyle" previouserrors="0" currenterrors="1" diff="1"/> </file> <file name="net/objectlab/qalab/parser/BuildStatMoverHandler.java"> <diff previousrun="-" currentrun="2005-06-17 11:42:03" type="pmd" previouserrors="0" currenterrors="3" diff="3"/> <diff previousrun="-" currentrun="2005-06-17 11:42:03" type="checkstyle" previouserrors="0" currenterrors="1" diff="1"/> </file> ... </up> <down> <file name="net/objectlab/qalab/ant/BuildStatMoverTask.java"> <diff previousrun="2005-06-17 11:42:03" currentrun="-" type="checkstyle" previouserrors="1" currenterrors="0" diff="-1"/> </file> <file name="net/objectlab/qalab/parser/BaseStatMerge.java"> <diff previousrun="2005-06-17 11:42:03" currentrun="-" type="pmd" previouserrors="2" currenterrors="0" diff="-2"/> <diff previousrun="2005-06-15 23:47:02" currentrun="2005-06-17 11:42:03" type="pmd" previouserrors="3" currenterrors="2" diff="-1"/> <diff previousrun="2005-06-17 11:42:03" currentrun="-" type="checkstyle" previouserrors="1" currenterrors="0" diff="-1"/> </file> </down> </moversreport>
From this report, it is possible to generate either HTML or XDOC files for either ant or maven use. We provide the following 2 examples: