First, I would wait until version 7. :-
Then, I would create two new modules:
hackySdt_Checkstyle
hackySensor_Checkstyle
The first would define an SDT called Checkstyle, along with DailyAnalysis,
Reduction functions, and DailyProjectDetails classes to provide basic
analysis capabilities.
The second would provide a sensor (either Ant-based or commandline based)
to collect Checkstyle info and send it off).
By waiting until Version 7, you can also take advantage of the new build
system, which will allow you to develop these modules at Referentia and
build your own custom local configuration of Hackystat that includes these
modules without having to touch the public files.
Cheers,
Philip
p.s. One could also imagine reusing the Issue sensor data type for
checkstyle data. This gets into the age-old question of "what's a
defect?". Right now, we have Issue data for configuration management
systems, (that's one kind of defect), UnitTest data for testing systems
(that's a second kind of defect), and ReviewIssue data for review systems
(a third kind). Checkstyle data would constitute a fourth kind of defect.
One of the nice things about keeping them all separate is that you can then
write telemetry definitions that display trends in each of these types of
defects over time and see if there are relationships.
--On Monday, October 3, 2005 11:18 PM -1000 Aaron Kagawa
<[EMAIL PROTECTED]> wrote:
Hey Guys,
I've recently been preaching the use of Elements of Java Style and making
sure we have good javadocs. For an organization that has many checkstyle
errors it would be cool to sense these with Hackystat to check the trend
of these types of errors. For example, are developers actually changing
their development process to adhere to some of these rules?
Sound like a good idea? Any ideas on what this SDT would be called?
thanks, aaron
