Hi Aaron,
Excellent info.
If you want to try to build Emma support into hackystat, that would be
totally great! Here's some tips:
(1) Check out the latest version 7 from svn. Build and do an all.junit as
normal to ensure that things are OK.
(2) Create a new file in hackyCore_Build called emma.build.xml. That's
where you'll put the emma implementation. Please prefix all your targets
with "hackyCore_Build."
(3) Add an import of emma.build.xml into build.xml.
(3) Unlike the previous hackystat build system, let's not use properties to
disable/enable coverage collection from the 'standard' freshStart target.
Instead, follow the StackyHack approach for jblanket of having a separate
top-level target that essentially recreates the freshStart/all.junit
behavior, wrapping the emma stuff around it. What this means is that there
will be no infiltration of emma-specific code into the other ant files. To
gather coverage, one will basically just invoke a single top-level target
like:
% hackyCore_Build> ant emma
Good luck, and let us know how it goes!
Cheers,
Philip
--On Sunday, October 30, 2005 10:04 PM -1000 Aaron Kagawa
<[EMAIL PROTECTED]> wrote:
If Emma is a consideration, then here are some comments about Emma.
- Emma appears to be ok with speed, according to the website it is "quit
fast". :) - Emma provides multiple levels of coverage information:
class, method, line, basic block. - Emma has a reporting function that is
pretty cool. It not only provides coverage information but links with
source code and highlights code that is covered and not covered. - Has
Ant support and can produce a XML report.
Jblanket versus Emma.
- Emma does not have a concept excluding one line methods.
- Emma works with Java1.5
- I personally haven't had a problem with Emma yet. Although, I haven't
tested it on a client/server application but, it seems that shouldn't be
a problem.
Hackystat Specific Information:
- I already implemented a sensor for Emma.
- BUT, the DailyProjectCoverage and I suspect the JavaCoverageReducer
doesn't distinguish between different granularities of coverage. But, I
implemented my sensor so that it can just send method level coverage,
which was a nice hack to solve that bug. - With a little Hacking, I
think you can get emma to provide the workspace in addition to the class
name. In addition to package/class names, Emma provides file name:
<srcfile
name="BogusStack.java">
<coverage
type="class, %" value="0% (0/1)"/>
<coverage
type="method, %" value="0% (0/5)"/>
<coverage
type="block, %" value="0% (0/28)"/>
<coverage
type="line, %" value="0% (0/11)"/>
If this is possible, then this would solve the Unit Test classname only
bogusity that Cam brought up. I wonder if eliminating the need for
JavaClassWorkspaceMap would increase processing speed by a noticeable
amount.
By the way, this hackystat-dev-l message contains a link to a StackyHack
that uses Emma and the Emma Sensor: <
http://www.mail-archive.com/[email protected]/msg01406.html >
As far as I can tell, Emma does everything Jblanket can do, plus a little
bit more; (1) supports Java 1.5 and (2) has more coverage levels. It
shouldn't be too hard to try Emma in the new Hackystat build design.
Also, it might be a little interesting to compare the speed and
correctness of JBlanket versus Emma.
I feel a little inspired to give this a try in Hackystat, that is if Emma
is a serious contender. But, probably my earliest attempt can be
Wednesday at the earliest.
thanks, aaron
At 06:30 PM 10/30/2005, you wrote:
Another JBlanket report error.
Let's talk about this at the CSDL meeting tomorrow.
Cheers,
Philip
--On Sunday, October 30, 2005 3:55 AM -1000 Qin Zhang <[EMAIL PROTECTED]>
wrote:
Hackystat build (configuration Hackystat-ALL) failed.
Build report is available at
http://xenia.ics.hawaii.edu/hackyDevSite/configurationBuildReport.do?year
=2005&month=10&day=30&configuration=Hackystat-ALL Build Time Stamp: Sun
Oct 30 03:55:18 HST 2005
