Hi all,

2) could/should the CppUnitTest Reducer have a filePattern parameter? The
UnitTest reducer has one. Its not clear why CppUnitTest shouldn't have
one.

Yes, it seems like a filePattern argument would be good. A bigger question: why do we need CppUnitTest Reducer at all? Why can't we just supply the appropriate filepattern to the UnitTest reducer? Mike?

These are both valid concerns.  Aaron, the CppUnitTestReducer could
definitely include a file pattern parameter.  On the other hand, Philip
is also correct.  Essentially, the CppUnitTestReducer is a stripped down
version of the UnitTestReducer.  It operates on the UnitTest SDT, in a
very similar manner.  At the time I wrote it, I was just getting into
telemetry (without really understanding it) and I wrote the CppUnit
reducer mainly because I thought that each stream would need its own
reduction function.

Obviously, this is incorrect.  I can generate the same streams with the
UnitTestReducer and will remove the CppUnitTestReducer package from
Hackystat.  Of course, the CppUnit sensor will remain intact.

Best regards,
Mike

Philip Johnson wrote:

--On Tuesday, March 29, 2005 2:28 AM -1000 Aaron Kagawa
<[EMAIL PROTECTED]> wrote:

1) could/should the Build Reducer have a filePattern parameter? I'm not
sure but couldn't other Projects have different build directories?
(Probably not.. the other two are better questions.)


Well, all reduction functions are project-specific anyway, so I'm not
sure that this adds
much value in this case (unless you have build.xmls embedded in
various places and want
to distinguish which one was invoked.)

2) could/should the CppUnitTest Reducer have a filePattern parameter?
The
UnitTest reducer has one. Its not clear why CppUnitTest shouldn't
have one.


Yes, it seems like a filePattern argument would be good. A bigger
question: why do we
need CppUnitTest Reducer at all? Why can't we just supply the
appropriate filepattern to
the UnitTest reducer?  Mike?


3) could/should the Issue Reducer have a filePattern parameter?
Issues can
be generated for different workspaces: hackyKernel, hackyStdExt, or even
hackyAnt/src/org/hackystat/stdext/sensor/ant/jira. At the very least, I
think we should be able to show different Issue streams for different
top
level modules.


I agree.

Cheers,
Philip

Reply via email to