[Sorry this post is a bit late, my email's had some trouble]

Keeping a history of metrics is an excellent idea.  We've been using a
tool called Hackystat, in conjunction with Maven and our daily
CruiseControl build, to gather and report on our metrics history.

Hackystat has a few important differences from both MavenHistory and
XRadar, which I'll try to list out to the best of my ability.  You can
get more info at their website.

1. Hackystat is tool-agnostic.  It allows you to collect information
from a variety of development tools.  This includes Maven, Ant,
Eclipse, JBuilder, Emacs, and the command-line.  Some of these
collection tools, or sensors, are fairly small and straight forward
(e.g. Ant and Maven).  You could likely add sensors to a new build
tool without much effort.  This is good if you want to keep your
history reporting even if you change your build process.

2. Hackystat provides tools for developers and for projects.

a. If you choose, you can send sensor information to a Hackystat
server about some IDE activities -- JUnit tests run in the IDE, files
changed, editor active time.  As a developer, you can then choose
whether to contribute your metrics to the project summary or not.  The
Hackystat tools can provide you with feedback and reports on your work
across projects.

b. A nightly build account can be setup to collect metrics about the
project that don't relate to any individual.  These include code size,
tests run, test coverage % and other such static analysis metrics.
The project tools can provide reports based on this information alone,
or across all invited developers that choose to participate in sending
their more fine-grained metrics.  The developer always retains control
of his/her metrics information, and can revoke that right from the
project at any time -- privacy is an important consideration in this
tool.

3. Hackystat is extensible.  You can extend Hackystat in several ways.
You can add new sensors for your tools to collect one of several
existing types of generic metrics (like a Build event, Activity event,
or UnitTest event).  You can create new types of metrics (e.g.
MyNewMetric event), and write a tool sensor to collect it (perhaps a
Maven plugin.jelly reads an XML file that contains MyNewMetrics).  And
you can create new Analysis templates for the web application.
There's also an easy way to customize and filter your views of many of
the existing metrics -- you define your own charts using simple syntax
like: JavaCoverage, (JavaCoverage-CoveredMethods,
JavaCoverage-UncoveredMethods)
.  This will create one graphic with two
charts.  The first has to total coverage %, and the second shows two
data lines, both the number of methods covered and the number of
methods not covered by tests.

4. Hackystat is a server-based application.  Sensors use SOAP to send
data to the server.  You can choose to drop the WAR file on your own
internal JSP/Servlet server, or to use their public Hackystat server
-- free for use by anyone.  I'd suggest using the internal server in
the long run.  It's nice to use the public server for a short time to
see how data is collected and reported.

5. Hackystat has an active set of 7 committers at the moment.  Because
some of them are paid, you're _extremely_ likely to see this project
continue well into the future.  It's a project that's been in the
works since at least 2001 (perhaps before), and it's got a bright
future.  This is a metrics system you can build a long term solution
on.

The best place to find information is probably the developer site.

http://hackydev.ics.hawaii.edu/ <http://hackydev.ics.hawaii.edu/>

When we began using Hackystat we were using Ant as our build system.
We switched to Maven, and they didn't have any sensors for Maven so I
recently wrote some.  I'm in the process of contributing them to
Hackystat -- I've spoken with them and they're excited to have the
Maven addition and see some natural connections between Maven and
Hackystat.  I'll post instructions on how to install the Maven plugins
and use them once the contribution is complete.

Hopefully that provides a decent overview of Hackystat for anyone
interested in using it to keep a metrics history.

Thanks,

Tim


A lot later than promised and still not quite as neat as I wanted it to be:

http://mavenhistorical.sourceforge.net

Matt.



-----Original Message-----
From: Morris, Jason [IT] [mailto:[EMAIL PROTECTED] Sent: 19 July 2004 15:00
To: Maven Users List
Subject: RE: History/trends in reports


I'll second (or third!) this proposal - I'd love to be able to track quality metrics from reports such as Checkstyle, jdepend etc over time. They always come in handy during appraisal season :-)

        Jason

-----Original Message-----
From: Jerome Lacoste [mailto:[EMAIL PROTECTED]
Sent: 19 July 2004 13:33
To: Maven Users List
Subject: RE: History/trends in reports


On Mon, 2004-07-19 at 11:52 +0100, Matt Read wrote:


> A colleague and I are actually working on a plugin right now to do > this, the default setup will plot a graph of total tests and %age > passing tests over time. Data is stored in a JDBC


datasource and data


> to be captured is currently specified as an filename and an


xpath to the data to gather.


> Graphs are then generated by a report plugin.
> > We're currently about a week away from releasing for testing, I'll > probably mention something on this list when we do.
> > Matt.



I am really interested in that. Do you have a generic format to store the data so that one could extend it to store many kind of data?


I was thinking of a DB as simple as that:

TABLE REPORTS
ReportID | DateTime | [ Comments]

TABLE REPORT_DATA
ReportID | Property | Value

Do not hesitate to copy me to mails related to the subject.

J


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]





--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to