Your question:
2) I noticed that the new FileMetric reducer with these parameters:
(1) FileType, such as '*', 'Java', 'C', 'Perl', etc. Optional. Default is '*' for all file types. (2) SizeMetricName, such as 'totalLines', 'classCount', 'functionCount', 'commentLines', 'numFiles', etc. Optional. Default is 'totalLines'. (3) FileFilterPattern, optional, default='**'.
First of all, what does etc mean? Where would there be a complete list of SizeMetricName values? Secondly, is there a SizeMetricName for sourceLines?
My answer:
SizeMetricName in FileMetric reducer is not hard-coded. It's impossible
to give an exhaustive list unless you give me an exhaustive list of
sensors sending file metric data.
Now the question becomes how you can find valid values for
SizeMetricName. Log into the account Hackystat receives file metric
data, use sensor data links to to see raw file metric data.
For example, CSDL has the following entry:
fileType = Java
file = C:\..\XmlSensorException.java
totalLines = 29
tool = SCLC
tstamp = 03/28/2006-05:05:24
pMap =
{tptoks=62,commentLines=17,sourceLines=12,blankLines=12,runtime=00000000}
So the valid entries are: totalLines, tptoks, commentLines, sourceLines,
blankLines, runtime
Note that everything in pMap is a valid size metric name include
runtime, this is because of FileMetric implementation.
long getMetricLong(String name) {
return Long.parseLong(this.getProperty(name));
}
I am sorry that there is confusion, but there is no way around this
because of the generic nature of file metric (the only guarantee I can
give is totalLines will always work).
Cheers,
Cedric
Aaron Akihisa Kagawa wrote:
Thanks for the recommendations.
I'm still not sure what I should be doing. One one hand, it seems a little
strange to mix LOC from SCLC and LOCC in the same telemetry trend, which would
happen if I start sending SCLC data (I'm assuming that LOCC and SCLC reports
different LOC numbers). On the other hand, doing recommendation (c) could also
get out of control. What happens if I start using Clover, PMD, FindBugs.
Basically, I interpret this functionality as only one tool can send data for a
specific metric and all others will be ignored. I'm not sure if that is good
or bad. For example, I was thinking that I could compare the telemetry trends
of LOCC-FileMetrics and SCLC-FileMetrics for Java code. Another example, is
what if I discovered that LOCC had a bug in it causing the metrics to be
incorrect. There would be no way to ignore that tool (short of deleting all the
XML elements).
Ok. I did some comparisons and found:
1) I just ran LOCC and SCLC on a large project and the values where different
for every metric (source lines of code, comment lines of code, and total
lines). Source LOC was the closest value. I'll try comparing the values on
some other projects later.
2) I noticed that the new FileMetric reducer with these parameters:
(1) FileType, such as '*', 'Java', 'C', 'Perl', etc. Optional. Default is '*' for all file types. (2) SizeMetricName, such as 'totalLines', 'classCount', 'functionCount', 'commentLines', 'numFiles', etc. Optional. Default is 'totalLines'. (3) FileFilterPattern, optional, default='**'.
First of all, what does etc mean? Where would there be a complete list of SizeMetricName values? Secondly, is there a SizeMetricName for sourceLines?
3) I found something confusing about SCLC. The command line has this:
[exec] Lines Blank Cmnts NCSL TPtoks
[exec] ====== ====== ====== ====== ======
======================================
The values for Lines is calculated with Lines = Blank + Cmnts + NCSL.
The size.xml report has totalLines = commentLines + sourceLines.
I thought that it was really strange to be adding the number of Blank lines to the total count as the Command Line output suggested.
Anyway, I think I'll just start sending SCLC data... If I can specify
SizeMetricName=sourceLines in my telemetry trends, I think I'd be a little
happier.
thanks, aaron
ps. by the way. my telemetry definitions are totally broken since I upgraded to
hackystat-uh-7.4.324. There needs to an easier way of making those definitions
files.. actually, I'm hoping that some one could send me one...
----- Original Message -----
From: Philip Johnson <[EMAIL PROTECTED]>
Date: Tuesday, March 28, 2006 9:35 am
Subject: Re: [HACKYSTAT-DEV-L] FileMetric reducer tool specific?
To: [email protected]
--On Tuesday, March 28, 2006 8:26 AM -1000 Aaron Kagawa
<[EMAIL PROTECTED]> wrote:
My concern was that I have a nice telemetry trend going for
FileMetric data by using
LOCC. I didn't want to disturb that trend when I start to send
SCLC data.
The basic question is how do I get access to a Hackystat data
with specific attributes.
Hi Aaron,
Well, there seem to be several options:
(a) modify the existing public functions (dailyprojectdata and
reducers) to support what
you want.
(b) you can develop a custom module with your own versions of
dailyprojectdata and
reducers to support what you want.
(c) you can check out your source code into a new directory as well
as the current
directory, and run SCLC over the code in the new directory. That
way you can define a
new project with its own workspace that does not overlap with the
current project, and
get distinct LOCC and SCLC counts.
Given your situation, it seems to me like (c) is the easiest and
most appropriate
alternative, because it seems like your situation is "transitional".
I am a bit reticent about (a) at this point, since I'm not sure of
its widespread
utility. If (c) satisfies your immediate needs, maybe start with
that and we can revisit
(a) if we discover additional situations in which it would be useful.
Cheers,
Philip
p.s. I am cc'ing this to hackystat-users-l. They can find the
entire thread in
<http://www.mail-archive.com/hackystat-dev-
[EMAIL PROTECTED]/msg02041.html>.
