start with hackyStdExt\bcml-compile\, which is the natue of the program. Here is the situation,
Assume we have runtime 10000010000 to hackyStdExt\bcml-compile\org\hackystat ... and same runtime
to hackyStdExt\src\... In DailyProjectCoverage we will have snapshot with workspaces hackyStdExt\bcml-compile\ ...
because we put hackyStdExt\bcml-compile\ ... in the map first and they will not be replaced by hackyStdExt\src\..
since runtime is not later than hackyStdExt\bcml-compile\ ..
Excluding BCML file metric can completely solve this. If we configure C:\cruiscontrol\instance-ALL, C:\cruiscontrol\instance-UH, C:\cruiscontrol\instance-JPL all of them as workspace roots the latest run on coverage will be used as the snapshot.
We can talk it tomorrow if I am not expressing it clearly here. Hongbing
(Cedric) Qin ZHANG wrote:
Class: org.hackystat.stdext.activity.sdt.Activity
Workspaces the above class are seen:
(1) hackyStdExt\bcml-compile\org\hackystat\stdext\activity\sdt\
(2) hackyStdExt\src\org\hackystat\stdext\activity\sdt\
(3) C:\CruiseControls\instance-UH\hacky\hackyStdExt\src\org\hackystat\stdext\activity\sdt\
(4) C:\CruiseControls\instance-JPL\hacky\hackyStdExt\src\org\hackystat\stdext\activity\sdt\
Pattern to match: hackyStdExt\bcml-compile\org\hackystat\stdext\activity\sdt\**
I say we need to test ALL the 4 workspaces against the pattern. So long as there is one workspace matching the pattern, we think the CLASS mathes the pattern. This way, bcml is irrelevant, because we always have workspace (2) from instance-ALL configuration.
Cheers,
Cedric
Hongbing Kou wrote:
1) go to the extras page on the Hackystat Public website
2) In the Telemetry Direct Streams Display command configure the selectors to have the following attributes:
- Report Type = table
- Project = Hackysta5-UH
- Interval = Day, September 3, 2004 - September 7, 2004
- Telemetry Streams:
- streams coverage = { JavaCoverage("NumOfCoveredMethods", "**\hackyStdExt\src\org\hackystat\stdext\activity\**") };
3) execute the command. you should see a table with 23 and 12 in the celss.
Cedric and I both repeated the above problem. Good news is that it is not a bug by careless.
Using coverage on class org.hackystat.stdext.activity.sdt.Activity as example. We have four workspaces map to this class :
hackyStdExt\bcml-compile\org\hackystat\stdext\activity\sdt\ (from BCML sensor because we had old file metric from BCML sensor)
hackyStdExt\src\org\hackystat\stdext\activity\sdt\ (from configuration hackystat-ALL)
C:\CruiseControls\instance-UH\hacky\hackyStdExt\src\org\hackystat\stdext\activity\sdt\ (from configuration hackystat-UH)
C:\CruiseControls\instance-JPL\hacky\hackyStdExt\src\org\hackystat\stdext\activity\sdt\ (from configuration hackystat-JPL)
in JavaClassWorkspaceMapManager.
When we build internal map to get coverage snapshot the first two will be used because they are sub-workspaces of the project's workspace hackyStdExt\ Only workspace hackyStdExt\bcml-compile\org\hackystat\stdext\activity\sdt\ is used to construct WorkspaceFile
hackyStdExt\bcml-compile\org\hackystat\stdext\activity\sdt\Activity.java, which is used by telemetry stream's FilePattern to match in computation because it goes first in the for-loop.
So the streams coverage = { JavaCoverage("NumOfCoveredMethods", "**\hackyStdExt\src\org\hackystat\stdext\activity\**") }; will
be zero because it doesn't match hackyStdExt\bcml-compile\org\hackystat\stdext\activity\sdt\Activity.java. You will get the
coverage information if you change your regular expression to :
streams coverage = { JavaCoverage("NumOfCoveredMethods", "**\org\hackystat\stdext\activity\**") };
NOTE : Excluding hackyStdExt\src
It solves the problem but brings up one question. Should we exclude the BCML file metric loading in JavaClassWorkspaceMapManager?
What do you guys think?
Thanks, Hongbing
