-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
v1.0.6 scoverage.coverage.xml not generated #29
Comments
You need to run |
Note, I've used Seems the testScoverage task should declare its outputs, since it is always regarded as UP-TO-DATE after the first run, even when removing the build/scoverage directory. But, even after specifying
in my build script, the task is not run:
Why doesn't Gradle run the task when an output is missing? But, even when I'm forcing to run the task more explicitely:
The task runs but the xml file is not created:
What gives? |
Oh, the XML file is not generated by testScoverage, but by compileScoverageScala. Still, this file is not generated with version 1.0.6. And it is not re-generated when the file is missing (for 1.0.5). \edit: workaround to force re-generation of the scoverage.coverage.xml file if it is missing: compileScoverageScala {
def coverageXml = file("${buildDir}/scoverage/scoverage.coverage.xml")
outputs.file coverageXml
doFirst {
if (!coverageXml.exists()) delete outputs
}
} |
I am hitting the same issue. I am using "org.scoverage:scalac-scoverage-plugin_2.10:1.0.2". Even after running testScoverage, with force run of compileScoverageScala, successfully, I am not getting any scoverage.coverage.xml.
1.0-5-g9c68988 works, but throws NPE for AnonymousFunction. :( |
Hi all,
As a workaround to ensure a manually deleted file is detected (this will be fixed), I think you strictly only require this:
In my testing (and as per the documentation) gradle detects that the file is missing, and re-runs the compilation task. It then runs the test and/or report task as requested. @SinghAsDev -https://groups.google.com/forum/#!topic/scala-code-coverage-tool/RTwYt4FyqSE suggests that scoverage doesn't work at all with 2.10, I'm not sure why a 2.10 package of 1.0.2 has been released. Is there any way you can re-test with 2.11? If not, please could you edit your comment to include the stacktrace of the NPE? @avdv - I think an early incarnation of the plugin used to skip the report task if there were no measured statements, but this was removed in favour of failing the build - there is no report to show if there are no measured statements. Please could you post a sample build file using 1.0.6 that demonstrates the issue? I'm unable to reproduce it with the following simple build (and a single scala source file). --edit please could you send it with the text output of a --debug run? I can reproduce the issue with an empty source directory; this doesn't create a measurement file at all.
|
@maiflai I do not get any coverage.xml with 2.11. I am using sonar-scoverage-plugin-1.1.0, gradle-scoverage:1.0.6 and SonarQube 4.2. I am trying to make coverage work for Apache Kafka, below id the modified build.gradle file. I ran ./gradlew :core:clean :core:testScoverage --stacktrace -PscalaVersion=2.11 --info. You can look at project structure of Kafka at https://github.com/apache/kafka.
After successfully running testScoverage, there is no coverage.xml generated.
|
That doesn't work when you're using the incremental zinc compiler, as the compiler will not recompile anything without the source files being changed.
I'll do when I'm back to work on monday. |
-- summary: I'll prepare a release later today. @avdv - thanks, I see what you mean - the scoverage compiler plugin only writes statement data for the files that were instrumented in the current run, therefore you cannot use incremental building as it forgets everything but the most recently compiled. I think the gradle scala plugin page suggests that it's better to use the Ant compiler if incremental building is not possible. I'm not sure I feel comfortable forcing the Ant compiler when compiling measured code, so I suppose the best thing to do is protect users by removing any previous compiled code. It seems there is an explicit option for this: @SinghAsDev - the issue here is that the gradle wrappers for Ant and Zinc behave in different ways. A change released in gradle-scoverage 1.0.6 handled an issue when using the Ant compiler with long paths. Unfortunately this introduced a bug when using the Zinc compiler. I've now added tests for both Ant and Zinc, but the Kafka build still fails, but now with a nasty internal compiler error. Please could you confirm that the stacktrace in question contains the following:
I think this particular issue will require closer analysis from the scalac-scoverage developers. There are several standard scalac warnings that are produced, and then warnings from the scoverage plugin. The next release should help you to prepare a bug report for them. |
@SinghAsDev - I think that if you use gradle-scoverage 1.0-5-g9c68988 and exclude
|
You are referring to commit a8a19c7, right? IMO, that change is questionable. If the ant compiler really has problems with spaces and does not properly escape then it is a gradle bug. I've seen this kind of patch way too often and it is never a good idea. First and foremost, you blindly enclose any parameter in double quotes, even those that already contain double quotes. Depending on which component is processing the quotes, this might or might not work. How about reverting that commit and fixing the problem at the root of the matter? |
@maiflai thanks for taking a look at the issue.
I have already tried this. The actual file that needs to be excluded is ZkUtils. However, with that I run into another issue, RadoBuransky/sonar-scoverage-plugin#10, for which I have been suggested to use gradle-scoverage 1.0.6. |
@avdv - yes, i can't fault your logic. My short-term view was that the change to the main gradle build will take some time to trickle through their release process, and if not carefully handled will break backwards-compatibility with other consumers. In the process of implementing a short-term hack, I managed to break the other compiler. As detailed in the Issue report behind that commit, I plan to submit a PR to the gradle team, but this will take a bit longer to do properly. I suspect I'll need another PR to look at the incremental build options. @SinghAsDev - I don't think the gradle scoverage (or SCCT) plugin has ever published the scoverage xml output file; it only publishes cobertura and HTML outputs. I suggest that you might try a sonar cobertura plugin in the meantime? |
@maiflai even if I try using 1.0-5-g9c68988 to get coverage.xml, reportScoverage fails with
The ST, below, is not that helpful. Any suggestion to get around this?
This is all I get with --full-stacktrace. |
@maiflai did you happen to take a look at this? |
Sorry, not yet - can you provide the command line arguments for the failing java process? Can you run the build in |
@avdv, @SinghAsDev - I think that we currently have two working versions that are released to maven central.
With that in mind, I plane to update the README to inform users, and I'll work on getting consistent fixes into the upstream gradle build. Once a new gradle build has been published, I can release a new version of the plugin which doesn't have the hacked workarounds. If a pressing feature-request arrives before gradle is fixed, then we'll have to review the hacks and probably add a further one so that both Ant and Zinc are supported by a single version of the plugin. I don't plan on maintaining branches. Does this sound reasonable? |
@maiflai below are the arguments
|
thanks - I think you've run into #13 here. can you try adding:
As per the link I plan to resolve this by pushing the reporting code up into the scalac-scoverage project. |
@maiflai its already there in my build.gradle. |
👍 sounds good. |
@maiflai sorry to bug you again on this, but did you happen to take a look at the reportScoverage issue? Should I create a separate issue for it? |
I don't see a gradle-scoverage jar in the classpath there, so I do think it's a duplicate of #13. I think it's just more complicated because the kafka build targets multiple scala versions. Have you discussed adding this feature with the kafka team? Do you plan to submit a PR to them? If you do plan on doing this, it may be helpful for you to fork their repository and then I can help you there. I've been able to get this working locally, but I need to see your changes in the whole to understand the missing pieces.
|
@maiflai I was able to get reportScoverage working. As you pointed out earlier, it was not getting gradle-scoverage in its classpath. Thanks for your help. I have one more question though. Is it possible to use sonarQube to display coverage using the cobertura report generated by scoverage? For some reason even after parsing the cobertura report, sonar is not reporting code coverage. |
Just noticed that cobertura.xml generated by gradle-scoverage just has summary of coverage. Is there any plan on making gradle-scoverage work with sonar-scoverage-plugin? |
Yes, I plan to publish the scoverage format in addition to the cobertura and html formats. |
Nice! Any estimate on by when will that be available? |
Sorry, there's a bit of a backlog and I think I prefer the functionality to be in a PR to scalac-scoverage (upstream). The summary coverage should be interesting in the meantime? And you can always review the HTML coverage outside of sonar. |
The report writers are in the scala-scoverage package. What is it you want On 18 January 2015 at 21:07, maiflai [email protected] wrote:
|
Cheers - yes, we're already using some of the classes directly but I think a CLI would help to simplify our consumption. I've raised scoverage/scalac-scoverage-plugin#81 - can we talk about it there? |
I've published 1.0.8, which now produces the scoverage xml file as part of its report. I think it also addresses the other issues referenced above - please could this be confimed? Note that it does not address the particular Kafka issue when compiling |
What's the kafka issue? On 8 February 2015 at 22:16, maiflai [email protected] wrote:
|
scoverage/scalac-scoverage-plugin#93 - NullPointerException during icode phase. |
Ah that one. ok On 8 February 2015 at 22:31, maiflai [email protected] wrote:
|
Cheers - just wanted to avoid any confusion over what was included in the release |
Confirmed, works for me. Thanks! 👍 The only thing I noticed is that even when you remove the build/scoverage directory, the |
Using version 1.0.6 of the gradle scoverage plugin, there is no xml file generated and the reportScoverage task fails:
When using version 1.0-5-g9c68988 it works.
The text was updated successfully, but these errors were encountered: