Community
Participate
Working Groups
Our JaCoCo Coverage builder logs but tolerates - see [1] - class file ID collisions instead of throwing exceptions - see [2]. This problem and symptoms have already been discussed within the context of bug 470374 comment 9 and following. I'd strongly recommend to switch to the default JaCoCo Coverage Builder and communicate (configuration) problems like this, that prevent a proper report from being build, to the end-user. [1] https://bitbucket.org/jubula/com.bredexsw.jubula.core/src/af1406d60fd79f8c35868834109bb58be7e81189/com.bredexsw.guidancer.autagent.monitoring.jacoco/src/com/bredexsw/guidancer/autagent/monitoring/jacoco/CoverageBuilder.java?at=master#CoverageBuilder.java-119 [2] http://www.eclemma.org/jacoco/trunk/doc/api/org/jacoco/core/analysis/CoverageBuilder.html
bela: Just a question. Have you discussed this issue? About, how should we manage the class id collision? https://jubula.atlassian.net/browse/JUB-1372 [...] alex: we didn't discuss it yet. My idea for now is to do the following: - switch the behaviour to not tolerate class ID collisions, with appropriate console output / log entries - add an option to the jacoco configuration area that allows the id collisions to be permitted (its default should be "off" - so that the default behaviour is correct, but users have the option to switch back to the incorrect (but maybe working) version. bela: alright
@Bela: Could you please make sure that your gerrit contribution(s) do not have the state "Merge Conflict" and? Thanks!
I've added comment 1 as we've discussed during todays (daily standup) meeting that our internal chat (which comment 1 is an excerpt of) is not a medium that's supposed to be used in any mean of permanent documentation (as it's e.g. not backed up).
(In reply to Markus Tiede from comment #2) > @Bela: Could you please make sure that your gerrit contribution(s) do not > have the state "Merge Conflict" and? Thanks! fixed
"Logging" configuration problems like this as a warning - see [1] - to the AUT-agent log file is not exactly what I had in mind with "communicate (configuration) problems to the end-user". Am I right with the assumption that the JaCoCo report generation after an ITE / testexec test run execution now silently fails and no report is getting written if such a collision occurs? In my opinion we should communicate this problem back (by adding the exception information to the corresponding response message - see [2]) to the ITE and at least properly fail the test execution core runtime job with an IStatus - see [3] - that's != OK; containing the descriptions that otherwise only getting logged. [1] https://bitbucket.org/jubula/com.bredexsw.jubula.core/commits/badf26b72153b4b75a534dbc4cd72d68666616e1?at=master [2] http://git.eclipse.org/c/jubula/org.eclipse.jubula.core.git/tree/org.eclipse.jubula.communication/src/org/eclipse/jubula/communication/internal/message/GetMonitoringDataResponseMessage.java [3] http://help.eclipse.org/mars/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/core/runtime/IStatus.html
I agree that the user should receive the information that the report failed with this reason in the ITE (and via the testexec).
Added notification, when the report failed.
For testexec, the exit code should not be changed, but an error line should be produced for the code coverage report building.
In ITE a dialog is shown in case of class file id collision. If I see well, in testexec the code coverage is not called.
Hi Bela, code coverage should be called in testexec when it is specified for the AUT configuration started. Can you check this?
Code coverage is called in testexec.
TO my knowledge, this has been resolved.
closing as resolved and no activity on this bug
