Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Elifarley C. Coelho
When I enable CodeCover in my Eclipse project, this error message appears:
"[FATAL] An error occured (sic) when trying to compile the instrumented sources."
After that, I select some classes and click on the "Use For Coverage Measurement" context menu item;
Then, I select a test class and select "Run As -> CodeCover Measurement for JUnit", which gives me this error message:
[FATAL] Error parsing the coverage log
Encountered "<EOF>" at line 0, column 0.
This is the stack trace:
Can anyone help me?
What happens is that the instrumented source code can't all be successfully compiled. Therefore while running the Program a Class (ProtocolImpl) added by the instrumenter to write the coverage log file can't be loaded and no coverage data be written.
Have you tried instrumenting a hello world project or SimpleJavaApp http://www.codecover.org/documentation/tutorials/how_to_complete.html to instrument at least something with your installation?
I've just tried running the plugin with the SimpleJavaApp project, and it worked perfectly well.
Now I have to find out what's wrong with my simple project.
I can assure you that Eclipse compiles my project without any problems, though.
What could I do to get full details on the error messages shown by the CodeCover plugin?
At the moment there's no simple way to increase the verbosity of the error messages of the Eclipse plugin. The only way is to increase the verbosity level by hand in the sources and rebuild the plugin (if you want to do this i can post some instructions).
I suggest you try to instrument your project with the batch (or Ant) version of CodeCover (which gives verbose error messages with the option -v). After that you can try to compile the instrumented sources.
Of course if your code is not of proprietary nature you can share it with us so we can figure out what's going wrong.
I find a solution for that. In my Case I only have to delete in the eclipse/plugins home directory the following folder "org.codecover.instrumentation.java.junit_1.0.0" and replaced it with the downloaded jar file. And now everythings work fine :)
Does your Eclipse project depend on other projects? CodeCover currently supports only single Eclipse projects without any dependencies, trying to instrument an Eclipse project with dependencies on other projects usually results in an InstrumentationException (during compilation of the instrumented sources the libraries of the projects depending on won't be included, resulting in compilation errors)
Is it planned to support projects which depend on other projects?
Yes, support for multiple projects is definitely a very important feature and at the moment it requires quite some effort to instrument software which is built from multiple source directories (or Eclipse projects of course). This is due to CodeCover's limitation of being able to instrument a single source directory only, therefore if you still want to use CodeCover with this kind of projects, you need to work around this limitation by moving all sources files to a single directory, perform the instrumentation and move the instrumented files back to their proper location. As CodeCover itself is built from multiple Eclipse projects for every component of CodeCover I have written a shell script which instruments CodeCover with itself (available in trunk/misc/instrument-codecover).
AFAIK no one is currently working on support for multiple source directories though. Patches welcome :)
Is there already a time schedule for support for multiple projects within eclipse?
Thank you very much,
I've created an Ant buildscript to use CodeCover for multiple Eclipse projects.
It copies all referenced project sources together into one source folder and instruments/compiles/runs the sources then.
You can download the sample Ant script here:
I just reported a bug partly related to this issue:
I just wanted to drop in and say that the lack of support for programs spanning over multiple Eclipse projects is a deal breaker for me (and probably everyone who does bigger projects). But other then that your project looks great!
P.S: I don't have the time to write a formal feature request and I don't know what exactly the current limitation is. However I suggest one of the devs posts a feature request to keep this idea tracked.
I can report having the same problem as the original poster. Moreover, I am able to instrument my source using the batch coverage tool without issue, both from the command line and from Ant.
I have multiple source folders (main and test) in a Maven-like layout. The src folder is a linked folder in my Eclipse project, though I have also tested using a src folder that is stored in the Eclipse project root. I have also examined the instrumented source files; nothing is amiss, with the anticipated exception of conflicting canonical names with the non-instrumented source. (If I remove the non-instrumented source folder from the build path, Eclipse reports no errors in any instrumented source file.)
Given this experience with the most recent version of the Eclipse plugin (220.127.116.11) versus the standalone CodeCover (18.104.22.168), I can only conclude that this issue is due to a misconfiguration of the Eclipse plugin.
I have the same problems with the codecover plugin in my projects which have some other projects as dependencies. To solve this problem I created a little patch for the CodeCoverCompilationParticipant which adds the output location of the dependent projects to the classpath of the runCommand. The eclipse build is now working fine and the coverage view displays the results of the current project, but no more.
The next steps would be to merge the test results, so after manually adding the codecover generated classes of the dependent projects to the classpath of the run configuration (which of course should be done later on by the codecover plugin) and running some testcases the coverage result can be found in the coverage log file. But this causes the test sessions view to don't show up the test runs anymore. After a lengthy debugger session I'm a little lost.
I'm really interested in solving this problem and use codecover for my eclipse projects furthermore. If some of the codecover developers can give me a hint I'll further work on this and of course contribute some patches for the project.
Btw I created a maven plugin some time ago which is in use in my company and working quite ok. If the codecover project is interested in, I'll try to open source this code.
for the problem caused by CodeCover not being able to instrument classes of projects of which the current project is dependent, I've found an easy workaround:
Select "Configure Build path" of the dependent project and go to "Libraries". There, click on "Add external class folder" and select the output folder of the other project (where its class files go). It's important to use "add external class folder" and not "add class folder", because the latter will add the path relative to the workspace location, which the CodeCoverCompilationParticipant will be unable to handle.