For Aaron's point (1) I have created an minor issue and assigned to
myself to investigate whether it's possible to get rid of
PatternMatcher.matches(String fileName).
It seems to me that all file matching in Hackystat should be done with
PatternMatcher.matches(WorkspaceFile workspaceFile).
The difference is the latter strips off workspace root before doing the
comparison.
Cheers,
Cedric
Philip Johnson wrote:
Great comments, Aaron! The screen adaptation of your Memoirs can't be
far off. :-)
Some quick thoughts:
* In the long run, the best way to simplify the debugging of the DPDs
is to reimplement them with the new design. In fact, my attempts to
debug the old DailyProjectFileMetrics class was what led me to the new
design in the first place.
* I agree that at some point, an abstract DPD class (or classes) could
significantly simplify DPD implementation. I'm just not sure yet of
the "design space" for DPDs, so I'm content to copy-and-modify for
now. I know the agilists are cringing, but there's a significant
ripple effect from refactoring and I want to understand the problem
better before going down that path.
* I agree with you that the "global" testuser is a bad idea, and in
fact the DPD documentation illustrates the better way, which is to
create a new test user with its own dataset:
<http://hackydev.ics.hawaii.edu/hackyDevSite/external/docbook/ch20s05.html>
* I also agree with you that the test framework should provide a way
to set the workspace root. I'm not sure why that wasn't done in the
first place. I've created a Jira issue:
<http://hackydev.ics.hawaii.edu:8080/browse/HACK-783>
* Again, the slowness issue with the dependency DPD should be
addressed by moving to the new design. This is actually good to do
while the old implementation is still around so that you can do
comparisons. There's some documentation on this at:
<http://hackydev.ics.hawaii.edu/hackyDevSite/external/docbook/ch20s06.html>
I'm still trying to get my head above water teaching-wise, and if that
happens, I hope to help make some tangible progress on some of these
issues.
Cheers,
Philip
--On Thursday, September 07, 2006 12:34 AM -1000 Aaron Kagawa
<[EMAIL PROTECTED]> wrote:
Hey Guys,
I just finished what i thought was going to be a minor fix, but it
turned out to be a
long and confusing fix, to the Workspace Dependency Analysis
(HACK-732). Here is what
I was having trouble with.
1) It took me a pretty long time to track bug in the
DailyProjectDependency2
implementation noted in HACK-779. It turns out that that the
FilePattern wasn't
matching against the Workspace (or WorkspaceFile) object. Instead it
was just matching
against the filePath in the Dependency data. This has since been
fixed by Cedric. So,
here is my point. Wouldn't it be nice if the individual DailyProjectData
implementations did not have to worry about that sort of detail.
Maybe after we
convert some more DPD implementations to the new design we can start
to think about
abstracting some of the common code out.
2) It also took me a while to find HACK-781. The problem is that
some users have
workspaces have file extensions. For some reason, I never thought to
check that and was
left scratching my head for a while why I was getting workspaces with
file extensions.
to get rid of these, i deleted the user.workspace.xml file and the
WorkspaceSeal. but
this isn't a long term solution. why are these workspaces being
created. i know that i
raised this issue before. what was the solution back then?
3) I had some minor issues with the creation of test projects. Our
test framework does
not allow use to set the workspace root. I'm not sure why that is.
I vote to change
that. Anyway, one obvious reason why we should do this is that the
first issue was not
detected until I set up a real project with a workspace root.
4) I've come to realize that our test data isn't very organized at
all. What would
happen if moduleA had FileMetric data on 2006-06-01.xml and moduleB
had a totally
different set of FileMetric data on the same day?
5) I think that the DailyProjectDependency2 implementation can
replace the old
DailyProjectDependency implementation. However, in the longer term I
think we would
want to redo the DPD to use the new design. Oh... By the way, can we
make a better
DrillDown section in the DailyProjectDetails for the dependency data?
What should go in
there?
Anyway, HACK-732 is completed. The only problem that I see right now
is that it is
pretty slow. It calculates the 4 dependency metrics for every
workspace that has Java
code in a project. Well it takes a while on my comp because I don't
have enough RAM
(anyone want to donate? I have a Dell Dimension 8400. hahaha).
thanks, Aaron
