Greetings Hackers!,
I just finished a marathon hacking session on 5 sensors for these tools:
- the Checkstyle coding standards tool (http://checkstyle.sourceforge.net/),
- the FindBugs static analyzer tool (http://findbugs.sourceforge.net/),
- the PMD static analysis tool (http://pmd.sourceforge.net/),
- the Emma coverage tool (http://emma.sourceforge.net/),
- the Jira Issue Management Server (http://www.atlassian.com/software/jira/)
-------------------------------------
To support Checkstyle, FindBugs, and PMD, I created a new Hackystat module
called hackyCodeIssue (basically, everything Jim Christenson asked for
http://www.mail-archive.com/hackystat-dev-l%40hawaii.edu/msg01198.html)
. This module contains the CodeIssue SDT, DailyProjectCodeIssue, and
CodeIssueReducer. You can find the initial version at
(http://csdl.ics.hawaii.edu/~kagawaa/newsensors/hackyCodeIssue.zip). The
CodeIssue SDT looks like the following.
<sensordatatypes>
<sensordatatype name="CodeIssue"
enabled="true"
wrapper="org.hackystat.stdext.codeissue.sdt.CodeIssue"
shellcommand="org.hackystat.stdext.codeissue.sdt.CodeIssueShellCommand"
docstring="Represents an CodeIssue instance"
contact="Aaron Kagawa ([EMAIL PROTECTED])" >
<entryattribute name="runtime" />
<entryattribute name="fileName" />
<entryattribute name="severity" />
<entryattribute name="message" />
<entryattribute name="type" />
<entryattribute name="line" />
<entryattribute name="column" />
<entryattribute name="data" />
</sensordatatype>
</sensordatatypes>
Initially, I hacked this SDT specifically for Checkstyle. But, also created
sensors for FindBugs and PMD to ensure that the SDT will work with these
other tools. It appears that there are some differences, which are not
necessarily problems). For example:
- Checkstyle is the only tool that provides column (i plan on taking this out).
- FindBugs only provides a class name, but I was able to generate a
fileName from the information it provides (see
http://csdl.ics.hawaii.edu/~kagawaa/newsensors/NewSensorDoc/CommandPrompt-ant-findbugs.txt)
- PMD provides a fileName and packageName and is pretty similar to Checkstyle.
In addition, I hacked a new feature into these Ant based sensors. These
sensors can optionally use the usermap. You can use this optional
attribute to send code issue data to Hackystat from any usermap account.
This is useful for Nightly Builds that build many different projects and
that have different hackystat users. For example, we could be building LOCC
in cruisecontrol and send the data to a locc hackystat user instead of
hacksytat-l.
<!-- Now send the code issue information to the hackystat server. -->
<taskdef name="hacky-checkstyle"
classname="org.hackystat.stdext.sensor.ant.checkstyle.CheckstyleSensor"
classpath="${lib.dir}/ant/sensorshell.jar" />
<!-- use usermapUser if you want to send data using usermaps -->
<!-- <hacky-checkstyle verbose="true"
usermapUser="checkstyleDefault" > -->
<hacky-checkstyle verbose="true" >
<fileset dir="${checkstyle.report}">
<include name="checkstyle.xml" />
</fileset>
</hacky-checkstyle>
Another thing I think is a useful standard is to make all Ant based sensors
(that process files, ie. xml files) always use a FileSet, instead of a
single file. Even though the tool will usually generate a single file.
Go to http://csdl.ics.hawaii.edu/~kagawaa/newsensors/NewSensorDoc/ to see
some screen shots and log files. For example the Checkstlye log looks
something like this:
#> CodeIssue [set, tool=Checkstyle]
set OK
#> CodeIssue [add, runtime=1129424384531,
fileName=C:\java\cvs\stackyHack\src\edu\hawaii\stack\BogusStack.java,
severity=error, message=Using the '.*' form of import should be avoided -
java.io.*.,
type=com.puppycrawl.tools.checkstyle.checks.AvoidStarImportCheck, line=3,
column=, data=]
CodeIssue add OK (1)
The DailyProjectCodeIssue supports two meta-data fields: (1) Total issues
and (2) Unique files with issues. For example, in StackyHack PMD found 56
violations in 6 files. (See
http://csdl.ics.hawaii.edu/~kagawaa/newsensors/NewSensorDoc/DailyProjectDetails-2005-10-15_2-pmd.JPG
). Currently, the only problem with the DailyProjectIssue is if a project
is using 2 or more Code Issue Sensors, the runtTime map gets replaced by
the last executed sensor. I could create a internal map that contains Tool
-> Runtime -> Workspace (no other DailyProjectData implementations use the
tool field like this). Or follow the example of DailyProjectJavaFileMetric
and create a specialized DailyProjectData implementation, but that seems
bogus.
These sensors live in hackyAnt
(http://csdl.ics.hawaii.edu/~kagawaa/newsensors/hackyAnt.zip), i also
hacked the installer code for each of these sensors. But, I did NOT do the
docbook!
The CodeIssue SDT and related components lives in hackyCodeIssue
(http://csdl.ics.hawaii.edu/~kagawaa/newsensors/hackyCodeIssue.zip). NO
docbook yet either!
-------------------------------------
To support the Emma Coverage tool, I created another sensor in hackyAnt
. To test out the sensor, I hacked some ant code and got it working with
StackyHack;
- here is my Ant code
http://csdl.ics.hawaii.edu/~kagawaa/newsensors/NewSensorDoc/build-emma.xml .
- here is the emma generated XML report
http://csdl.ics.hawaii.edu/~kagawaa/newsensors/NewSensorDoc/ToolReport-emma.xml.
- here is the hackystat coverage data
http://csdl.ics.hawaii.edu/~kagawaa/newsensors/NewSensorDoc/SensorData-Coverage-2005-10-15.xml
Everything seems ok with the sensor, BUT there is a problem with the
DailyProjectCoverage. The current implementation does not use the
granularity field, thus when you run the Daily Project Details analysis
each coverage entry is used as a method level entry. For example,
Hackystat thinks StackyHack contains 415 methods (see
http://csdl.ics.hawaii.edu/~kagawaa/newsensors/NewSensorDoc/DailyProjectDetails-2005-10-15_2-emma.JPG).
Anyone want to volunteer to fix that? Otherwise, I guess I will.
NOTE: Jblanket doesn't work in StackyHack.
this sensors live in hackyAnt
(http://csdl.ics.hawaii.edu/~kagawaa/newsensors/hackyAnt.zip), i also
hacked the installer code for the sensors. But, I did NOT do the docbook!
-------------------------------------
I've made a couple of improvements to the Jira sensor.
1) the JiraIssueExtractor can get issue xml files from login protected Jira
projects. It can also work through SSL. This code is based on the Maven
Jira Plugin (http://maven.apache.org/reference/plugins/jira/).
2) the JiraIssueExtractorSensor has a couple more optional attributes:
- workspaceRoot - use this attribute if your jira server has a custom
workspace field
- workspace - use this attribute if you don't have a custom workspace field
(ikayzo.org is using this, but i hacked a specialized sensor for them. now
we can just release a single sensor. i also plan to use this sensor at work)
- unassignedIssueOwner - use this attribute if you want to send unassigned
data to a hackystat account
- defaultUser - user this attribute if you want to disregard the issue
owner and send all data to a single hackystat account, useful in situations
when jira users don't have hackystat accounts or don't know that hackystat
exists (ikayzo.org is using this, but i hacked a specialized sensor for
them. now we can just release a single sensor. i also plan to use this
sensor at work)
Instead of directly hacking the existing Jira sensor, I made another sensor
call Jira2 that lives in hackyAnt. I suppose Philip can decide whether to
immediately replace the old jira sensor or to roll out both version.
The Jira2 sensor uses commons-httpclient-2.0.2 and commons-logging . I've
haven't hacked the installer code for Jira2 yet. Although, I don't think it
will be too hard. Also, there is no Unit Test to test the use of the
httpclient code yet. I think Version 7's ant improvements will help me with
that (ie. being able to set my own classpath for junit).
------------------------------------
If your interested in trying out some of these tools and sensors download
http://csdl.ics.hawaii.edu/~kagawaa/newsensors/stackyHack.zip. This zip
file is pretty big; I put the distributions of Emma, FindBugs, and PMD in
this file so people can try it out. if I ever commit this code, I will take
them out. Also note that, I put sensorshell.jar into the
StackyHack/lib/ant directory and that the http://hackystat.ics.hawaii.edu
server doesn't support the CodeIssue yet. So, you can enable the sensors
and look at the log files that will store the data offline, but be sure to
delete that offline data after you are done so you don't send bogus data to
the public hackystat server.
------------------------------------
Philip: please advise on whether I can do the following:
- import hackyCodeIssue into CVS
- commit new hackyAnt sensors (Emma, FindBugs, PMD, Checkstyle).
- commit new hackyAnt Jira2 sensor or blow away old Jira sensor.
- commit my changes to the hackyBuild build.xml and build.utils.xml
By the way, can you the docbook docs for me?
THANKS, aaron
