Jira Sensor:
I figured out the problem with my use of the Jira Sensor through SSL. It turns 
out that
my certificate had expired.  So, I followed the instructions that I wrote in 
section
14.16.2.6 (doc book) and everything was ok.  I suppose it was a little bit 
difficult to
remember that certificate issue.  I also found an bug in the Jira Sensor, see
http://hackydev.ics.hawaii.edu:8080/browse/HACK-598 .

Glad it's resolved, and thanks for posting the docbook bug.  I've fixed it.

Ant Log File Sensor:
Julie has agreed to help take a look at creating either a XSL/XML Data or Ant 
Log
Sensor, see http://hackydev.ics.hawaii.edu:8080/browse/HACK-599.  I suppose the 
first
thing we should try to do is the XSL transformation.  As I said previously, I 
would
like an Ant Log based sensor because I have a bunch of archived Ant logs from 
cruise
control builds.

Sounds good, and a reasonable issue to address in the next release cycle.

SCLC and XmlData Sensor and SVN Sensor:
I'm about to dive into these sensors in the next week or so. Anything I should 
know
about SCLC and XmlData? For example, should I not run LOCC and SCLC in the same 
build?

I just looked at DailyProjectFileMetric, and it (correctly) uses the batch of FileMetric data that has the last runtime stamp for any particular day. This leaves you with the following design alternatives:

(1) Use either LOCC or SCLC, but not both. This avoids problems that could occur if on some days you run LOCC last, and on other days you run SCLC last, resulting in different total counts for your system (since LOCC basically counts only Java while SCLC counts 21 language types).

(2) If you want to take advantage of the language breadth of SCLC and the language depth of LOCC for the specific case of Java (i.e. method-level counts), then you have to do two things: (a) Make sure you always run LOCC first and then SCLC. That guarantees that the "generic" DailyProjectFileMetrics and the reducers that depend upon it will see the data generated by the same tool every day.

(b) Write a new, LOCC-specific DailyProjectData instance (or maybe an "OO" specific DailyProjectData instance) which finds the last timestamped FileMetric batch containing method-level counts, then write a reducer on top of that. Then you can have a parallel set of analyses on just your Java code that dive into the greater structural detail provided by LOCC.

Hope this helps,

Cheers,
Philip

Reply via email to