The JavaClassWorkspaceMapManager implements SensorListener. When new entries comes it builds a mapping for that user. BUT, that mechanism doesn't not read in the past information (ie. buildCache). Therefore, the mapping will be incomplete!
To fix this I to make an improvement to the new entry mechanism to read in all the data the first time a new entry comes in. We didn't do this in the past because reading in past FileMetric data would have been memory intensive. Now we have a persistent mapping file it should be fine.
thanks, aaron
At 06:36 AM 11/19/2004 -1000, (Cedric) Qin ZHANG wrote:
Now everything is back normal if you run ICS413-TestSizeAndCoverage for hacky2004-all. I think it's related to the fact that I refreshed the mapper for hackystat-l user last night.
But definitely that mapper implementation does not look stable.
Cheers,
Cedric
Philip Johnson wrote:Here's some more data: the daily project summary does have coverage:
hacky2004-all on 18-Nov-2004
Active Time: 13.25 (total), 11.08 (yours)
Build: 20 (total), 12 (successful)
Coverage: 81.9% (overall), 2686 (covered methods), 592 (uncovered methods)
Unit Tests: 1059/0/0 (total p/f/e), 0/0/0 (yours)
Churn: 1002/1970 (total lines added/deleted), 681/148 (yours)
Commits: 36 (total files committed), 11 (yours)
Performance: 26 (total tests), 4 (failures)
--On Friday, November 19, 2004 1:40 AM -1000 "(Cedric) Qin ZHANG" <[EMAIL PROTECTED]> wrote:
Java coverage reduction function returns 0, and thus all coverage related charts show nothing on them.
Coverage SDT contains only class names, but the pattern it takes is for file names. Therefore, internally, Java coverage reduction function consults java workspace mapper to do the coversion.
It seems to me that workspace mapper is not working correctly. Related mapper files was changed during Nov 8 - 11. Following are my observations:
(1) When I build on my local computer with public hackystat data downloaded from the public server, everything's working fine.
(2) On the public server, I run "Display Workspace Map" with "Refresh=no" as "hackystat-l" (the first time), I see all our class names mapped to "C:\CruiseControls\instance-COCOMO\....". Note that "C:\CruiseControls\instance-COCOMO" is not set as hackystat-l's workspace root, since we only need instance-ALL's data.
(3) On the public server, I run "Display Workspace Map" again with "Refresh=yes", then the result changed. Now I see C:\CruiseControls\instance-ALL\ and C:\CruiseControls\instance-UH\. But still JavaCoverage reduction function returns all zero.
My question to Aaron:
(1) Does the mapper writes intermediate result to hard disk? (2) Shouldn't refresh and non-refresh give the same result? (3) Internally, the mapper must need to scan file metrics data from a certain start date to build the map. The only time user needs to do a refresh is to change that scan start date. Since you do not allow user to change that scan start data on the web interface, what's the point offering such a refresh choice?
Cheers,
Cedric
