Hey Guys,
Some questions about the sensors.
Ant Log Sensor:
I want to use the Ant Build sensor for CruiseControl builds, but I
think I tried to use that sensor and I'm not sure if I got it working
properly (I don't remember the problems that I ran into). One idea
that I had was to leverage the Ant logs that CruiseControl creates as
a data source and not have to install the Ant Build sensor during run
time. Do you see any problems with using the Log file opposed to our
current approach? For example, can we get the same information?
SVN Sensor:
I have a little concern that the SVN Sensor creates a large process
when running on historical commits (using the fromData and toDate
attributes). How hard would the Subversion Server be hit if I ran the
sensor for 6 months of historical data? Basically, I would want to
know if this is something I should do during the weekend.
Similarly, does the daily invocation of the SVN sensor create a
similar overhead? Basically, I would want to know if I should run
this during 11:00pm instead of 9:00am.
One last thing. We do not have individual Hackystat accounts. Thus,
server side sensors send data to one central account (or one account
per project). I believe it is possible to create this mapping in the
usermaps, but at what cost? Would sending this data in this manner
significantly reduce the usefulness of the data?
I'm not sure why I'm trying to stay away from individual Hackystat accounts.
JUnit Sensor:
Well, this question isn't really about the JUnit sensor; its has to
do more with the DailyProjectUnitTest class. Like I said earlier we
do not utilize client side sensors, thus the current
DailyProjectUnitTest implementation does more harm than good in this
situation. Basically, I do not care how many (the aggregation) unit
test were run in a day, because it always comes from the same user
(our automated build user). All I want to know is the number of unit
test (snapshot) that were ran during the last official build. Well,
maybe an aggregation and snap shot would be useful.
Emma, FindBugs, and PMD Sensors:
These sensors are great, but I do not want to actually run these
tools if the sensors are not available. And I would want to run these
tools only if the sensors are available (for example in CruiseControl
builds). What would be the best practice on how to make this
possible? Would using the available be the best option? Note that
some of the developers actually run our cruisecontrol target before
committing code.
Jira Sensor:
I haven't been able to get the Jira Sensor (formally Jira2) to work
since the latest upgrades. I'm not sure if its the upgrades or some
settings on my local server. The problem is that the extractor can't
seem to login through SSL (it was able to before). I guess this is
not really a question, but just an FYI. I will look into the problem.
Eclipse warnings about Sensors:
Is there any way how to get rid of those pesky "taskdf class
org.hackystat.sensor.* cannot be found" warnings in Eclipse without
installing the sensors? Those are probably especially irritating to
my developers who have no clue what Hackystat is. My current thought
would be to make a separate Ant build file that contains the Ant
sensor targets and invoke that separately. Any other ideas?
Telemetry Control Center:
Its my belief that the Telemetry Control Center is much apart of the
Hackystat interface as the Web commands. Any thoughts about allowing
that application to be downloaded via the Hackystat webpage?
Finally,...
Eclipse Sensor:
At some point, I would like to introduce client side sensors like the
Eclipse sensor. I belive the "Big Brother" issue would be a
factor. One idea that I had was to send all DevEvents to one single
Hackystat account. Thus, a developer can hide amongst the rest of the
project members. Would that be a bad idea? I'm just trying to
figure out a way to minimize the "big brother" feel.
thanks, aaron
