Hi, Philip,
With some effort on the new DailyProjectFileMetric implementation I am
close to know
the cause of this problem but I do not know how to fix it logically.
First of all, the behaviors of workspace you experienced are correct.
The short answer is
that our workspaces are case insensitive.
>1. Defines a project using the workspace "C:\".
We can define a project with any workspace programmatically but we can only
define a project with top-level workspace on the web interface.
>2. Retrieves the workspace associated with the project. It's now "c:\"
Workspaces are case insensitive. If we have two workspaces "C:\" and
"c:\", only one of them will be shown in the top-level workspace list in
Hackytstat preference page. Depending on the order they appear we
will see either the lowercase workspace c:\ or uppercase workspace C:\.
TestCourseProjectAnalysis happens to see the lowercase workspace c:\
when it creates a project to test.
>3. Obtain some FileMetric data associated with the project, and get the
top-level workspace. It's now "C:". Note that it is back to upper case,
and that the final "\" is now missing.
This top-level workspace is extracted from path field in FileMetric sensor
data entry so it is in the same case as in FileMetric data entry.
It explains why project's top-level workspace is in lowercase c: and
FileMetric
data's top-level workspace is uppercase C:. Regarding to the missed
trailing
backslash, it was stripped off in method
Workspace.getTopLevelWorkspaceName(String)
by design. Appending backslash will not make too much difference, I think.
The new implementation of DailyProjectFileMetric caches metric values using
project's top-level workspace. In your case LOC to top-level workspace c:\
was cached. So far I don't know why it cannot compute LOC to top-level
workspace C:\ correctly by reading the code. Hope my explanation can give
you some insights.
Thanks,
Hongbing
Philip Johnson wrote:
Greetings, all (but especially Hongbing),
After cutting over to the new version of DailyProjectFileMetric, the
hackyApp_Course module had a junit failure. In investigating the cause of
this failure, I came across an inconsistency in the way Workspaces are
processed. I want to illustrate the problem and then seek advice on how we
should deal with it.
The summary of the problem is that the Workspace mechanisms for dealing
with the "drive letter" workspace are inconsistent: sometimes the drive
letter is implicitly lower-cased, and sometimes it is not. In addition, the
"top-level" workspace when the drive letter is in the path doesn't match
the workspaces in the project. These inconsistencies break my class.
I've written some sample code below to illustrate the problem. Here's what it
does in a nutshell:
1. Defines a project using the workspace "C:\".
2. Retrieves the workspace associated with the project. It's now "c:\"
3. Obtain some FileMetric data associated with the project, and get the
top-level workspace. It's now "C:". Note that it is back to upper case,
and that the final "\" is now missing.
The code:
private static void illustrateWorkspaceCaseProblem() throws Exception {
Logger logger = ServerProperties.getInstance().getLogger();
Day day = Day.getInstance("01-March-2003");
User user = UserManager.getInstance().getTestUser();
WorkspaceCache workspaceCache = WorkspaceCache.getInstance();
// Create an UPPER CASE workspace to add to project. Note: no workspace
root!
Workspace work = workspaceCache.getWorkspace(user, "C:\\");
logger.warning("The workspace added to the project is upper case: " + work);
// Define a project for March 1, 2003 test data using this workspace.
TreeSet workspaceSet = new TreeSet();
workspaceSet.add(work);
Project testProject =
ProjectManager.getInstance().createTestProjectClientSide("March1Data",
user, day, day.inc(3), workspaceSet);
// Get the top-level workspace for this project.
Set projectWorkspaceSet = testProject.getWorkspaceSetCopy();
//The following shows that the project workspace set contains the single string
"c:\"
logger.warning("But the project workspace is lower-case: " +
projectWorkspaceSet);
// But when we get the files for this day, the top-level workspace is NOT lowercased.
SensorDataType sdt = SdtManager.getInstance().getSdt("FileMetric");
SensorData data = SensorDataCache.getInstance().getSensorData(sdt,
user.getUserKey(), day);
for (Iterator j = data.iterator(); j.hasNext();) {
FileMetric fileMetric = (FileMetric) j.next();
Workspace workspace = workspaceCache.getWorkspace(user,
fileMetric.getFileName());
String toplevelworkspace = workspace.getTopLevelWorkspaceName();
logger.warning("But the FileMetric workspaces are back to upper case: " +
toplevelworkspace);
}
}
The output from running the code:
06/06 14:25:17 The workspace added to the project is upper case: C:\
06/06 14:25:17 But the project workspace is lower-case: [c:\]
06/06 14:25:17 But the FileMetric workspaces are back to upper case: C:
06/06 14:25:17 But the FileMetric workspaces are back to upper case: C:
06/06 14:25:17 But the FileMetric workspaces are back to upper case: C:
There are a number of issues here:
1. Is this the appropriate behavior for workspace manipulation? Am I missing
something?
2. I have been under the assumption that drive letters should always be
eliminated from workspaces by using WorkspaceRoots. Yet this is not
checked for, and there appear to be many test cases that were written
without defining workspace roots to that drive letters appear in the
workspace. I didn't write tests for this in DailyProjectFileMetric because
I assumed this would not happen in practice. Are we supposed to allow this?
3. A simple solution might be to change
Workspace.getTopLevelWorkspaceName() to return "c:\" rather than "C:" in
this situation. But that might well have far-reaching ripple effects.
Hongbing will need to do an impact analysis.
4. I can, I guess, make my own version of
Workspace.getTopLevelWorkspaceName() that returns "c:\" in these situations, and
hopefully solve this problem. But it's an ugly hack.
What do other people think? I will continue working on this to get a
work-around
in place so that hackyApp_Course does not fail. In the interim, we can still
deploy
the hackystat-UH configuration.
Cheers,
Philip
