It looks as if the Travis build runs validateJVM twice

[mikejcurry]

Well, four times actually I think, twice for 2.10 and twice for 2.11. It might reduce build times a little if this was optimized.

coverage="$sbt_cmd coverage validateJVM coverageReport && bash <(curl -s https://codecov.io/bash)"
scala_jvm="$sbt_cmd validateJVM"
run_cmd="$coverage && $scala_js && $scala_jvm $publish_cmd"

validateJVM is run as part of both coverage and as part of scala_jvm

I would put through a PR myself, suggesting the change, but I wasn't sure which to remove. I guess, the $coverage one needs to stay and the $scala_jvm one should be removed?

[ceedubs]

Good catch!

Maybe we should name it coverage_jvm and get rid of scala_jvm?

[mikejcurry]

Sounds reasonable. I should say, I don't know enough about how travis and codecov.io work to be sure I wouldn't be breaking something, e.g. maybe the code coverage needs a completely separate build for some reason?

[mikejcurry]

@inthenow, @non, do either of you know if it is safe to change this as described? I know that some code coverage tools for Java I've used in the past instrument the bytecode, making the built software unsuitable for release really, and so I'm wondering if the multiple calls to validateJVM is intentional to prevent that or something. I couldn't find any documentation either way for the codecov tool.

[ghost]

Well, it is intentional that, because of coverage, we compile twice. That said, I'm not 100% sure it is still needed, so that could be investigated. But either way, we do need to see the coverage for 2.10/2.11 and coverage takes this into account

[ghost]

Ok, the byte code is modified so two runs per version are required. And validateJVM is essentially just an alias for compile;test so is still needed. For the coverage run, test is needed for the coverage, and then clean is run. So we then compile the code from new, so the tests need to be re-run too.

[ghost]

So, I think it should stay as-is. But...

It's perhaps unclear why it is done this way - perhaps a PR to document this is what is required? Either way, it looks like a PR is needed

[mikejcurry]

Sounds good - I'll put through a PR to document some time soon. Probably as a comment in the file I guess.

[mikejcurry]

#701 added some explanatory docs to the script.