Skip to content
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

java.io.FileNotFoundException: .../build/service/target/scala-2.11/scoverage-data/scoverage.measurements.1 (No such file or directory) #228

Closed
sfosdal opened this issue Jul 12, 2017 · 9 comments

Comments

@sfosdal
Copy link

sfosdal commented Jul 12, 2017

I am getting the following error when running an assembled jar:

Exception in thread "main" java.lang.ExceptionInInitializerError
	at com.avvo.data.qa_recommendation.service.Main$.delayedEndpoint$com$avvo$data$qa_recommendation$service$Main$1(Main.scala:13)
	at com.avvo.data.qa_recommendation.service.Main$delayedInit$body.apply(Main.scala:11)
	at scala.Function0$class.apply$mcV$sp(Function0.scala:34)
	at scala.runtime.AbstractFunction0.apply$mcV$sp(AbstractFunction0.scala:12)
	at scala.App$$anonfun$main$1.apply(App.scala:76)
	at scala.App$$anonfun$main$1.apply(App.scala:76)
	at scala.collection.immutable.List.foreach(List.scala:392)
	at scala.collection.generic.TraversableForwarder$class.foreach(TraversableForwarder.scala:35)
	at scala.App$class.main(App.scala:76)
	at com.avvo.data.qa_recommendation.service.Main$.main(Main.scala:11)
	at com.avvo.data.qa_recommendation.service.Main.main(Main.scala)
Caused by: java.io.FileNotFoundException: /opt/qa-recommendation/build/service/target/scala-2.11/scoverage-data/scoverage.measurements.1 (No such file or directory)
	at java.io.FileOutputStream.open0(Native Method)
	at java.io.FileOutputStream.open(FileOutputStream.java:270)
	at java.io.FileOutputStream.<init>(FileOutputStream.java:213)
	at java.io.FileWriter.<init>(FileWriter.java:107)
	at scoverage.Invoker$$anonfun$1.apply(Invoker.scala:42)
	at scoverage.Invoker$$anonfun$1.apply(Invoker.scala:42)
	at scala.collection.concurrent.TrieMap.getOrElseUpdate(TrieMap.scala:901)
	at scoverage.Invoker$.invoked(Invoker.scala:42)
	at com.avvo.data.qa_recommendation.service.BuildInfo$.<init>(BuildInfo.scala:8)
	at com.avvo.data.qa_recommendation.service.BuildInfo$.<clinit>(BuildInfo.scala)
	... 11 more

In my build.sbt I do have:
coverageEnabled := true

however when assembling use the following:
sbt -no-colors coverageOff assembly

I am currently using version 1.5.0:
addSbtPlugin("org.scoverage" % "sbt-scoverage" % "1.5.0")

with sbt: 0.13.15

@gslowikowski
Copy link
Member

coverageOff doesn't override coverageEnabled := true setting. Instead of using coverageEnabled := true, just call coverage (or coverageOn) to turn coverage on.

@sfosdal
Copy link
Author

sfosdal commented Oct 2, 2017

finally found time to try this. worked great for me. Thanks!

@sfosdal sfosdal closed this as completed Oct 2, 2017
@naveencotha-zt
Copy link

I have these two lines in the build.sbt of my single module sbt project,

coverageEnabled.in(Test, test) := true
coverageEnabled in(Compile, compile) := false

I still do see this error, when I build the jar file with assembly.

@gslowikowski
Copy link
Member

@naveencotha-zt provide a simple test project, please.

@naveencotha-zt
Copy link

@gslowikowski posted it here, with a very simple readme

@gslowikowski
Copy link
Member

@naveencotha-zt don't run assembly task when coverage is turned on.

Proper calls:

sbt clean coverage test coverageReport coverageOff assembly

or

sbt clean assembly coverage test coverageReport

(BTW semicolons are not required when you specify tasks without quotation marks)

@naveencotha-zt
Copy link

naveencotha-zt commented Nov 6, 2018

Thanks for the clarification, so if I do something like sbt clean coverage test coverageReport coverageOff assembly

  1. This makes tests run twice, to make the tests run only once, the command looks like
    sbt clean coverage test coverageReport coverageOff "set test in assembly := {}" assembly, Is there an elegant way?

  2. Can I remove these two lines from my sbt

@gslowikowski
Copy link
Member

ad. 1 - your test project contains no tests :)
ad. 2 - yes, remove these lines

@naveencotha-zt
Copy link

Thanks, @gslowikowski, yeah you are right, I don't have any tests in the sample project, although I do have tests in my actual project.

bartholomews pushed a commit to bartholomews/fsclient that referenced this issue Jan 25, 2020
jaydoane pushed a commit to cloudant-labs/clouseau that referenced this issue Feb 14, 2025
The `coverageEnabled := true` in `build.sbt` instruments the code unconditionally.
The right way to enable coverage is to do

`sbt clean coverageOn test coverageReport coverageAggregate`

Also it is important to do `sbt clean` after doing the coverage, otherwise the code
stay instrumented.

The problems to figure out:

1. when instrumented code is included into jar this jar doesn't work on another machine
2. apparently the `sbt clean` is not sufficient and the `target` directories for each
subproject need to be removed
3. setting `coverageEnabled := false` and trying to issue `sbt clean coverageOn ...`
doesn't produce report files
4. when `sbt ... coverageOn test` is used junit xml test report is not generated
5. we should run eunit tests using coverage as well
```
sbt clean coverageOn
make all-tests
sbt coverageReport coverageAggregate
```
6. we need to include mango tests into all-tests target

See following

- scoverage/sbt-scoverage#84
- scoverage/sbt-scoverage#228
- scoverage/sbt-scoverage#306
- https://github.com/viktortnk/kafka-storm-starter/blob/de6eac4ae635e0e54981a92555de05071c14518a/README.md?plain=1#L340C1-L342C58
- https://github.com/Facsimile/facsimile/blob/409dd67fd291161414401c97d128bf65c0fcc30f/Facsimile.sbt#L458
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants