Hi.
Ok, I think, excluding the problematic methods is really reasonable in this case. I did compile all my stuff with debug mode, but the JiBX binder adds additional no-debug-mode methods. Excluding them should be feasable, as these methods won't have any unit-test coverage and will just mess up the results (I cannot test them because I don't know what they are suppposed to do (and they are even not existant in the sources) and it doesn't make any sense to test them because they are automatically generated by JibX). An other solution could be (a guy from the JiBX mailinglist recommended that) to compile all files to a temporary folder, add the JibX stuff methods, decompile them and recompile them with debug-on (this could easily be done using the optional jad-ant-task would not require and exclusions. It's just adding a few lines to my local build file. But still these methods won't have coverage and will just lower the overall coverage).
Just tell me which solution you like better and I'll do it.
Cheers, Christoph
Philip Johnson wrote:
--On Friday, March 18, 2005 12:48 PM -0700 Tim Shadel <[EMAIL PROTECTED]> wrote:
java.lang.UnsupportedOperationException: No line numbers detected in org.hackystat.app.cgqm.implementation.TestMetric1.<init>. Either remove the 'oneLineFile' tag or turn debug on when compiling.
Another option is to exclude that particular constructor from coverage, using the excludeIndividualMethods option.
--Tim
I'd prefer that Christoph not do that. We should exclude individual methods when there is a good semantic reason in terms of the analysis, not simply because it's easier than turning on debugging.
Cheers, Philip
