Greetings, all,
I was able to reproduce the hackyApp_Course failure locally, and I've just
committed changes that fix the problem (locally).
Basically, I defined the following method in DailyProjectData that I now use in
DailyProjectFileMetrics:
/**
* Ensures that the Top-level workspace name extracted from the Workspace is
lowercase
* in the case of a drive name for consistency with the workspace names
returned from
* the Project definition.
* HACK to workaround inconsistency in Workspace implemenation.
* @param workspace The workspace.
* @return The top-level workspace string associated with workspace. If a
drive letter,
* it is lower-cased.
*/
public static String getTopLevelWorkspaceNameHack(Workspace workspace) {
String topLevelName = workspace.getTopLevelWorkspaceName();
if (topLevelName.charAt(1) == ':') {
// It's a drive letter, so lowercase it.
topLevelName = topLevelName.toLowerCase();
}
return topLevelName;
}
This was all that was necessary. Once we're in the 7.5 release cycle, I'd like
Hongbing to see if this should become the default behavior for the
workspace.getTopLevelWorkspaceName() method.
There is a deeper point here, actually. We've had discussions in the past
where questions have been raised about whether we should have a class to build
the intermediate data structures required for DailyProjectDetails, and a
different class to build the intermediate data structures for telemetry.
What I think DailyProjectFileMetric now illustrates is how and why it makes
sense to keep things together in one class. The key design issue is to
maintain an internal cache that is keyed by FilePatterns, which include (but
are not limited to) the set of FilePatterns corresponding to the "top-level
workspaces" used in DailyProjectDetails. To make this work, there needs to be
a way to easily take the top-level workspaces obtained from the Project
instance, and find their corresponding FilePatterns in the cache. (This is
where the bug occurred, since the way you get a top-level workspace containing
a drive letter "top-down" from the project instance is not consistent with the
way you get a top-level workspace containing a drive letter "bottom up" from
the FileMetric data.
I think Cedric or Hongbing may have attempted this approach before, but
abandoned it when they saw the performance implications. I also needed to
write the custom match2() method that makes FilePattern matching fast in the
special case of top-level workspaces in order to make this design unification
practical from a performance point of view.
Anyway, the current pedagogical problem is that DailyProjectFileMetric is the
most complex DailyProjectData class by a mile, and so is in some ways not the
simplest example to learn from. Once we've got 7.4 out the door, I will take a
couple of days and reimplement one of the other DailyProjectData classes using
this design pattern so that it is easier to see.
Cheers,
Philip
