Updating report task to be on par with sbt plugin

[Kwestor]

In sbt-scoverage plugin, report task is much more detailed. This commit
updates gradle version of report task to be on par with it's sbt
counterpart.

Updated version of task brings 4 new configuration parameters:

• coverageOutputCobertura
• coverageOutputXML
• coverageOutputHTML
• coverageDebug

All could be used to enable/disable different outputs. All but last one
defaults to true. Readme is updated with this information.

Code in ScoverageWriter.java is re-written from sbt-scoverage and
converted to Java. It could be moved to scalac-scoverage-runtime to be
used by all plugins. It's not inlined in SingleReportApp.java because
it'll be used also in ScoverageAggregate task (in next PR).

If there is no test data in project report task now only issues a warning
and not crash (it's important for multi-project setups without test
code/code to test in some sub-projects).

Disclaimer required by the lawyers (it's covered by Apache 2, but they want me to include it in PR description):

THE FOLLOWING DISCLAIMER APPLIES TO ALL SOFTWARE CODE AND OTHER MATERIALS CONTRIBUTED IN CONNECTION WITH THIS SOFTWARE:
THIS SOFTWARE IS LICENSED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE AND ANY WARRANTY OF NON-INFRINGEMENT, ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. THIS SOFTWARE MAY BE REDISTRIBUTED TO OTHERS ONLY BY EFFECTIVELY USING THIS OR ANOTHER EQUIVALENT DISCLAIMER IN ADDITION TO ANY OTHER REQUIRED LICENSE TERMS.
ONLY THE SOFTWARE CODE AND OTHER MATERIALS CONTRIBUTED IN CONNECTION WITH THIS SOFTWARE, IF ANY, THAT ARE ATTACHED TO (OR OTHERWISE ACCOMPANY) THIS SUBMISSION (AND ORDINARY COURSE CONTRIBUTIONS OF FUTURES PATCHES THERETO) ARE TO BE CONSIDERED A CONTRIBUTION. NO OTHER SOFTWARE CODE OR MATERIALS ARE A CONTRIBUTION.

[Kwestor]

After this PR I have similar one ready for aggregateScoverage task, with acceptance tests checking if aggregation works ok.

[gslowikowski]

Hi guys

I see you are working on extending reports. Where can I get the sources with your all patches from?
I'm curious how you solved some aspects of running Scoverage in multimodule projects and aggregating reports.
There are many differences between SBT, Gradle and Maven plugins now. I would like to reduce them. You are aligning Gradle plugin with SBT, but are paying attention to different aspects. For example, I would like to have multiple source roots per module support, see my proposal scoverage/scalac-scoverage-plugin#104. This is important for single modules and even more important for aggregated reports. See my version of aggregated report here https://github.com/gslowikowski/scoverage-maven-samples/tree/issue104/aggregator/target.commited_to_git/site/scoverage, there are no module_x/src/main/scala paths, just package names.

[maiflai]

Sorry, I've been away from the computer for the past week.

re: a single source with all patches - I don't think there is a single place containing all the discussions regarding scoverage reporting. They are currently split across the gradle-scoverage repository (and forks thereof) and the scalac-scoverage-plugin repository.

I agree with you that we want to reduce the differences between the plugins, and in particular I'm not sure I agree with merging this particular PR for gradle-scoverage (it looks like a port of my PR for the scalac-scoverage-plugin which has stalled).

I've commented directly on scoverage/scalac-scoverage-plugin#104.

[Kwestor]

No problem.

I agree it looks similar to your PR to scalac-scoverage, as I say in code comment in file: Copied from sbt-scoverage and converted to Java to avoid dependency to Scala.

For me it doesn't matter if this code ends up here or in plugin, we just need those options and currently we are using custom build from my branch.

We've postponed scoverage integration into next sprint (in 2 weeks), and I'll be glad to submit some other changes and test if reporting and aggregation works ok in our (rather convoluted) setup.

[maiflai]

Ah, yes - thanks :-)

I think then that this PR allows the user to selectively control which reports are generated, but it defaults to the current behaviour.

I'll look into #41 first, then #39, then this if that's ok?

[Kwestor]

Great!

[Kwestor]

Hi! How it's going with my PRs?

[maiflai]

Hi!

Sorry, I was distracted - paternity leave can be a little sleepless...

#41 - I don't have permission to change the default branch, nor to set up a github.io page in the scoverage project, so I'm struggling with the documentation update. I think I prefer the separate website approach, or perhaps we should document this in the release notes? @sksamuel - would it be possible to give me access?

#39 - I seem to recall submitting Kwestor#2 in relation to your question at the end of that conversation. Do we still have an issue with spaced Windows directories?

[Kwestor]

#39 - it seems all tests pass now, thanks!

[Kwestor]

Concerning #41 I can wait, two others are more important to me.