I am making the assumption that you don't use tool 1 on module A and
tool 2 on module B. Instead, you use tool 1 and tool2 on all the modules
you have.
I have pondered for some time whether I should allow daily project file
metric and reducers to return tool specific information.
But that seems to be a system wide change. Even if we do allow tool
specific information, we still have to decide what to do in case the
client does not specify a tool name. It's better that we have a
system-wide consistent policy. I'll leave that decision to our project
manager.
-Cedric
Philip Johnson wrote:
Thanks, Cedric, for the clarification!
I just relooked at the DailyProjectFileMetric implementation and
noticed that the internal map involves a tool key, which I missed the
first time around.
I am happy with the current behavior for now, and it certainly has the
advantage of allowing people to send data using multiple size counting
tools and extracting the results with a single DailyProjectData instance.
My concern, not to be addressed for this release, is with the
"tie-breaking behavior" of selecting the largest numeric value to
return. Although it's quick, dirty, and simple, it's not necessarily
the case IMHO that the _biggest_ value is always the _right_ value for
a given metric sent by multiple tools. It's easy for me to envision
all sorts of pathological cases where you get a mixture of metrics
from different tools, and even the same metric from different tools
depending upon the workspace. That's almost certainly not the correct
behavior.
Downstream, we'll probably want to revise the interface such that
clients (such as reduction functions) can do things like specify that
they want "the totalLines metric provided by Tool X", or even "the
list of all TotalLines metric computed by all tools sending data on
this day". That way, if a client cares, they can control what values
they are getting. But Cedric's current solution is a reasonable one
that simplifies the interface and supports future enhancement.
This discussion also reveals to me the increasing need for a Reference
Guide chapter on DailyProjectData functions that documents these kinds
of design decisions! But that will unfortunately have to wait until 7.4.
Cheers,
Philip
--On Tuesday, March 07, 2006 1:19 PM -1000 "(Cedric) Qin ZHANG"
<[EMAIL PROTECTED]> wrote:
Let me clear something up about DailyProjectFileMetric implementation:
You can use both LOCC and SCLC to send file metric data. The sequence
you run the tools
doesn't matter. DailyProjectFileMetric will generate the latest batch
of sensor data
for each tool used.
In other words, there is a latest batch for LOCC, another latest
batch for SCLC, and
possibly still another one if you have more than 2 sensors sending
file metric data.
When you call DailyProjectFileMetric.getFileMetric(metricName), it
will look into each
batch data, compute that metric, and return the one with largest value.
An example:
LOCC file metric data has functionCount information.
SCLC file metric does not have functionCount.
When you call getFileMetric("functionCount"), the LOCC data return a
number (say 100
functions), but the SCLC data return 0 (because it has no function
count information).
In the end 100 is returned.
In case of total lines, all sensors send this information. Then the
largest total lines
win.
Cheers,
Cedric
Philip Johnson wrote:
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
