First off, great work, Aaron!
Here is the Emma Report
(http://csdl.ics.hawaii.edu/~kagawaa/emma/emma/coverage.html) for the
following modules:
Wow. Pretty cool report. We've _got_ to get us some of that. :-)
It seems pretty fast too.
In JBlanket's defense, the apparent speed of Emma might really be due to
the overall speedup in the build (and particularly, the increases in JUnit
tests since all tests for a module now execute within a single JVM).
1) I had to manually duplicate the freshStart target with a bunch of
<antcall> targets. I had to do this because I had to instrument the class
files before hotDeployHackystat.
OK, I'll look at this more closely. Maybe I can refactor freshStart or
something.
2) Emma requires a shutdown of tomcat to collect server side coverage
information.
That's hopefully not a big deal for us. Getting coverage info is kind of a
special case situation anyway.
3) The Emma report can be linked to the source code, which provides
colored highlighting of covered methods, blocks, and lines. To use this
feature, I had to "hard code" the source directories.
The way we can deal with this is to include the required sourcepath
declaration within modules.build.xml. Eventually, this whole file will be
autogenerated.
4) I had to re-write a custom makeJUnit macrodef to include some
systemproperties and an altered classpath.
:
Anyway, because of the overriding of makeJUnit macrodef I get all these
override echos
No big deal.
5) According to Emma's FAQ
(http://emma.sourceforge.net/faq.html#q.runtime.appservers), I had to add
emma.jar to <jre dire>/lib/ext. The FAQ says that it might be possible
to add the jar file to tomcat's classpath. I'll look into this more.
That's OK. We might want to check for the presence of that file when
running the emma target to make sure it's set up appropriately.
6) I'm using the latest beta distribution of Emma, because it has some
new features. But, I'm not sure if I using them or not. I will
investigate if I can revert back to the stable release.
OK.
To conclude, it seems that Emma might be a good fit for Hackystat.
Absolutely.
Some questions:
- Philip: can I go ahead and import the emma.build.xml into SVN?
Yes! And please go ahead and figure out a way to put any hard-coded module
references you need for Emma into modules.build.xml. I think you basically
need to set up a <fileset> with an id in modules.build.xml, and then use
refid to refer to it within emma.build.xml.
If I understand you correctly, you're overriding the current makeJUnit
macrodef. What I think this implies is that instead of putting adding
<import file="emma.build.xml"/> into build.xml, what you want to do is
structure your emma.build.xml file so that you instead import whatever
build files (excluding junit.build.xml) that you need. Then, to invoke
emma, you would do:
ant -f emma.build.xml hackyCore_Build.emma
In other words, this structure ensures that the override of the makeJUnit
macrodef occurs only when one is actually wanting to run Emma.
There might be a better way to do this; I'll keep thinking about it.
- Any suggestions on how to make the emma.build.xml better?
Let me know when it's imported and I'll check it out.
- Does Jblanket work in the V7 build? I want to compare JBlanket's
information to Emma's. Actually, it would be great if someone in CSDL can
help me out with this task.
I will get JBlanket running in the next few days. It will indeed be
interesting to compare the two.
Cheers,
Philip
