Open arahuja opened 9 years ago
My guess is that you have multi-module project containing duplicate package/class names. If this is the case, there is no current solution available because it's impossible to detect the correct submodule from aggregated Cobertura report. See issue #56 for more details.
If the earlier is not the case then I would need a bit more information about the issue. Are there any weird encodings or new line characters used in the code files?
@trautonen Thanks for the reply - this is a single module project and I don't believe package names should overlap at all - but I can double check in case it accidently happened. There also should not be any weird encodings, or new line characters used.
Is possible to check which source file is causing the error or get more information on what can't be found?
Ok. I created a new snapshot that improves the exception message for the out of bounds issue. Could you add Sonatype's snapshot repository to your project and test with the 3.2.0-SNAPSHOT
version.
<repository>
<id>sonatype-nexus-snapshots</id>
<name>Sonatype Nexus Snapshots</name>
<url>https://oss.sonatype.org/content/repositories/snapshots</url>
<releases>
<enabled>false</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
With those above set run your build for example on local machine with mvn -U -DdryRun=true org.eluder.coveralls:coveralls-maven-plugin:report
Thanks for the update - I had to add to it pluginRepositories
actually.
Running that says
Build error: Line number 292 is greater than the source file src/main/scala/org/hammerlab/guacamole/LociSet.scala size
which is true, that file only has 286 lines.
There are many tests that list a line number higher than that in the cobertura file unfortunately - the tests that seem to have higher line number on an inner class, could that be causing issues? Must be an issue with scoverage than.
Thanks!
Can you create test project (for scoverage) generating wrong line numbers?
I think I have this working in the repo @arahuja and I are concerned about, so we can probably close this.
Either something was fixed here or in maven-coveralls-plugin in the last year, or we both were tricked by not diligently-enough running mvn clean
between running other non-scoverage coverage-report-generation tools and attempting with scoverage (which definitely happened to me at least once yesterday before I ultimately got things working).
I described my full configs for Maven+Scala+Scoverage+Coveralls here: https://github.com/trautonen/coveralls-maven-plugin/issues/98#issuecomment-242131735.
Thanks for following up!
I'm using scoverage:1.1.0 to generate a cobertura report and it is created in
target/cobertura.xml
Using coveralls maven plugin:3.1.0
I get the following exception: