At 12:39 AM 9/16/2004 -1000, you wrote:
To make it clear. Only one kind of workspaces is used because it is the snapshot over the system. We probably don't want to have 4 daily coverage snapshots, I don't see the point to have 4 same things. In our cases we have workspaces
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.
If I understand you correctly, I respectfully disagree. :) Excluding BCML filemetrics because of the "generated" workspaces is a Hack!
The following is my view on the correction of this problem. (although, I'm not sure how correct I am, because I'm relatively new to the whole workspace and workspace mapping thing).
Workspaces the for org.hackystat.stdext.activity.sdt.Activity 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\
** Assume that all of the workspaces were generated with the same latest runtime attribute.
In theory, the idealistic mapping would be one workspace to one classpath. But, because of the missing configuration of the UH and JPL workspace roots and the "generated" BCML workspace, we have a many to one mapping (workspaces to classpath). It is important to realize that ALL those workspaces are valid
In the case of Coverage, we are concerned about the other direction of the mapping. Mapping from classpath to workspaces (a one to many mapping). It seems to me that ALL workspaces should be given credit for any information generated by a single classpath. Currently, the Coverage mechanism _incorrectly_ picks the first workspace to give "credit" for a particular classpath (again, assume that all of the workspaces were generated with the same latest runtime attribute.)
In other words consider this, the following telemetry stream currently works:
streams coverage = { JavaCoverage("NumOfCoveredMethods", " "**\org\hackystat\stdext\activity\**") };
which is a hack because only this works (due to the incorrect "picking" of a single workspace).
streams coverage = { JavaCoverage("NumOfCoveredMethods", "**\hackyStdExt\bcml-compile\org\hackystat\stdext\activity\sdt\**") };
but, I would claim these all should work:
streams coverage = { JavaCoverage("NumOfCoveredMethods", "**\hackyStdExt\bcml-compile\org\hackystat\stdext\activity\sdt\**") };
streams coverage = { JavaCoverage("NumOfCoveredMethods", "**\hackyStdExt\src\org\hackystat\stdext\activity\sdt\**") };
streams coverage = { JavaCoverage("NumOfCoveredMethods", "C:\CruiseControls\instance-UH\hacky\hackyStdExt\src\org\hackystat\stdext\activity\sdt\ ") };
streams coverage = { JavaCoverage("NumOfCoveredMethods", "C:\CruiseControls\instance-JPL\hacky\hackyStdExt\src\org\hackystat\stdext\activity\sdt\ ") };
I would claim that this approach is better in a couple of ways.
(1) It doesn't force the Sensor Designers to have to send "actual" workspaces. As in the case of BCML. In other words, I don't think it would be a good design choice to exclude BCML data just because it has a "generated" workspace different from the "actual" workspace. It seems perfectly reasonable that source code be moved to another location to run a tool on it and send it off to the server.
(2) It is perfectly valid to have a workspace like "C:\CruiseControls\instance.. " therefore, we shouldn't just pick one workspace for a given classpath as Cedric suggests. We shouldn't try to guess which workspace maps to a classpath. We should use them all.
(3) It provides more flexibility.
What do you guys think about this? Please correct me if I have a bad "conceptual model" (haha. I'm taking HCI) of workspaces and workspace mapping.
thanks, aaron
