Philip,
Thought I would add my two cents :)
In this case, one implementation seems better than two assuming that functionality is the same.
The key functionality needed is not just "open" issues. That's useful of course, but you also want events to represent issues discovered, closed, re-opened, etc. To me, that data is far more useful for making decisions than simply open issues. Of course, having all the appropriate metadata for the issues including severity, type, etc is necessary as well.
The key difference between the 2 implementations is whether real-time is better than static. I think static is fine since the most granular setting for telemetry reports is daily metrics.
Todd
Philip Johnson wrote:
Hi Tim,
I probably don't know enough to even ask the question, but isn't this something you can just include in the daily build to guarantee you get a snapshot every day?
No, it's us who didn't know enough to ask the question!
Maven has a JIRA task that downloads the open issues as XML and then formats them into HTML reports when it builds its project documentation. There's a Java class that simply downloads the file needed to support the Maven work. It'd seem possible to take the next step and send that data to the Hackystat server.
http://maven.apache.org/reference/plugins/jira/faq.html
That's an excellent approach that's very consistent with our other build-time, Ant-based sensors.
If we do it this way, then we've built two independent Jira sensors: (1) a sensor that's integrated with Jira itself as a plug-in which sends events in 'real-time'; and (2) an Ant-based sensor that requests a 'report' (at this point, of open issues) as part of daily build data collection activities.
In summary, we could (as I had proposed in the prior email) implement sensor (2) using the same approach we did for (1). Or, we could keep the two completely separate, as described in the previous paragraph.
My question: Is keeping the two kinds of sensor implementations separate a bug or a feature?
Cheers, Philip
