I have successfully intrumented jars, generated .ec files, and created reports.
But, i am now having problems with data collection -- an .ec file is not being generated.
it could be that my instrumented jars are not making it into the classpath (i am using overwrite, though).
my .em file is generated, i then cd to a different directory to run my tests. could this cause a problem. how do the instrumented classes know where the .em file is located?
can i turn on a debug mode, or logging?
any help, or pointers, would be great.
the tool looks good, and the ability to instrument already-compiled jars/classes, and the ant integration, is very helpful.
thanks,
scott
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If an EMMA-instrumented class makes it into the classpath and actually gets loaded by the JVM, EMMA will send a string to System.out that says something like "collecting runtime coverage data". Similarly, when the JVM exits EMMA will print a message about dumping coverage data and that message will show the output file pathname. If that is not happening, there are several possibilities:
(a) you have not added the instrumented jars to the classpath
(b) you aren't actually using any of the instrumented classes (unlikely, but possible). Or maybe you have excluded too much with an instrumentation filter?
(c) System.out has been disabled or somehow reset by the application (again, unlikely but possible)
There are some options you could give to EMMA tools to enable debug level tracing, but this would not help with your problem (because EMMA runtime code is small and does not trace much beyond what I mentioned above (unlike the tools themselves)).
Regarding having control over the location of coverage.ec file, I recommend you read Chapter 3 of the reference manual ("EMMA property reference"). The property responsible for this file location is "coverage.out.file". Again, it is doc'ed in the reference manual. Briefly, it defaults to "coverage.ec" in the *JVM current dir* which is where the JVM was launched from (watch out for any shell scripts that you might be using to run java, as they can obfuscate the VM current dir; it is also the same as the "user.dir" system property). However, you can override this property (change the file name, or it absolute or relative pathname).
There are a multitude of ways to do this. The easiest options are:
(1) use a JVM system property when running the instrumented classes:
java -Demma.coverage.out.file-<some abs pathname to be sure> ...
(2) create a file named emma.properties that sets this:
coverage.out.file = <again, some absolute pathname to be sure>
and add it to the JVM classpath when running the instrumented classes.
Hope this helps,
Vlad.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have successfully intrumented jars, generated .ec files, and created reports.
But, i am now having problems with data collection -- an .ec file is not being generated.
it could be that my instrumented jars are not making it into the classpath (i am using overwrite, though).
my .em file is generated, i then cd to a different directory to run my tests. could this cause a problem. how do the instrumented classes know where the .em file is located?
can i turn on a debug mode, or logging?
any help, or pointers, would be great.
the tool looks good, and the ability to instrument already-compiled jars/classes, and the ant integration, is very helpful.
thanks,
scott
Scott,
If an EMMA-instrumented class makes it into the classpath and actually gets loaded by the JVM, EMMA will send a string to System.out that says something like "collecting runtime coverage data". Similarly, when the JVM exits EMMA will print a message about dumping coverage data and that message will show the output file pathname. If that is not happening, there are several possibilities:
(a) you have not added the instrumented jars to the classpath
(b) you aren't actually using any of the instrumented classes (unlikely, but possible). Or maybe you have excluded too much with an instrumentation filter?
(c) System.out has been disabled or somehow reset by the application (again, unlikely but possible)
There are some options you could give to EMMA tools to enable debug level tracing, but this would not help with your problem (because EMMA runtime code is small and does not trace much beyond what I mentioned above (unlike the tools themselves)).
Regarding having control over the location of coverage.ec file, I recommend you read Chapter 3 of the reference manual ("EMMA property reference"). The property responsible for this file location is "coverage.out.file". Again, it is doc'ed in the reference manual. Briefly, it defaults to "coverage.ec" in the *JVM current dir* which is where the JVM was launched from (watch out for any shell scripts that you might be using to run java, as they can obfuscate the VM current dir; it is also the same as the "user.dir" system property). However, you can override this property (change the file name, or it absolute or relative pathname).
There are a multitude of ways to do this. The easiest options are:
(1) use a JVM system property when running the instrumented classes:
java -Demma.coverage.out.file-<some abs pathname to be sure> ...
(2) create a file named emma.properties that sets this:
coverage.out.file = <again, some absolute pathname to be sure>
and add it to the JVM classpath when running the instrumented classes.
Hope this helps,
Vlad.
BTW, I forgot to explain that the *.em file is not used by the instrumented classes at runtime. It is only used at report generation time.
vlad,
our build was picking up the 'wrong' jars. so, i did instrument the incorrect jars. thanks, for your help.
scott