provide a CLI for writing reports from generated results

[maiflai]

A first attempt to expose an API that can be called from SBT, gradle and Maven

[Kwestor]

Why a CLI API and not a standard Scala one? It's much easier to call scala method than to run Scala program. Not to mention you can then return some values, and not interface via files somewhere in target directory.

Jerzy

On 19 Jan 2015, at 18:14, maiflai notifications@github.com wrote:

A first attempt to expose an API that can be called from SBT, gradle and Maven

You can view, comment on, or merge this pull request online at:

#82

Commit Summary

provide a CLI for writing reports from generated results
File Changes

M project/Scoverage.scala (1)
A scalac-scoverage-plugin/src/main/scala/scoverage/report/ReportWriter.scala (116)
Patch Links:

https://github.com/scoverage/scalac-scoverage-plugin/pull/82.patch
https://github.com/scoverage/scalac-scoverage-plugin/pull/82.diff
—
Reply to this email directly or view it on GitHub.

[maiflai]

I explained my reasoning here: scoverage/gradle-scoverage#22

[Kwestor]

Ok, I misunserstood that post. You do want to remove compile-time dependency between gradle-scoverage and scalac-scoverage completely, it makes sense.

But could tou expose a Scala API and on top of it CLI API? Running separate JVM from sbt just to create a report seems like an overkill to me.

I can help with coding/documenting it.

[maiflai]

No worries - re: your JVM concerns: I think that launching a new JVM with such a small classpath is a) trivial and b) cheap. Especially when compared to the other work involved just in compiling a small Scala project.

maiflai/gradle-scct@5005d4d#diff-9a3db29361db74217cd9a3d2e970a3e6R137 shows the change required to the gradle build to remove the compile-time dependency.

I agree that the SBT plugin (being tightly coupled to Scala) will indeed use the Scala API (the ReportWriter). The CLI exposes this via the Reports App for consumption by the non-Scala gradle and maven clients.

Actually creating these reports (three formats, one of which a dynamically generated website) is complex, but the client API should make it appear simple.

[Kwestor]

Thanks. Did you remove messages with paths where reports are generated by purpose? I think it's very helpful for user to just copy URI from console to browser/editor (or just ctrl+click it).

[maiflai]

Ah - no, that's an accident :-)

Cheers, I'll update the PR.

[Kwestor]

I like to have messages prefixed with plugin name, like [scoverage] Cannot specify (...), what do you think about that?

[gslowikowski]

Is this good place to discuss differences between SBT/Maven and gradle regarding dependencies, classpaths, using different versions of scalac plugin, etc?

[sksamuel]

Might as well be.
On 21 Jan 2015 08:57, "Grzegorz Slowikowski" notifications@github.com
wrote:

Is this good place to discuss differences between SBT/Maven and gradle
regarding dependencies, classpaths, using different versions of scalac
plugin, etc?

—
Reply to this email directly or view it on GitHub
#82 (comment)
.

[gslowikowski]

Every scoverage-maven-plugin version depends on specific scalac-scoverage-plugin version.
See https://github.com/scoverage/scoverage-maven-plugin/blob/scoverage-maven-plugin-1.0.2/pom.xml#L92
Users don't neew to add anything to their projects. The right version of scalac-scoverage-runtime dependency is added to project's classpath in scoverage life cycle based on Scala version and plugin version used. For example if project uses Scala 2.11.4 and declares plugin version 1.0.2
scalac-scoverage-runtime_2.11 version 1.0.2 will be used.
What if you want another version of the plugin/runtime, for example 1.0.1? You have to override plugin's dependency:

                <plugin>
                    <groupId>org.scoverage</groupId>
                    <artifactId>scoverage-maven-plugin</artifactId>
                    <version>1.0.2</version>
                    <dependencies>
                        <dependency>
                            <groupId>org.scoverage</groupId>
                            <artifactId>scalac-scoverage-plugin_2.10</artifactId>
                            <version>1.0.1</version>
                        </dependency>
                    </dependencies>
                </plugin>

The whole configuration is on the plugin side.
I don't know if I'm, right, but sbt-scoverage plugin configuration is similar, am I right?

In Gradle example plugin version is declared in:
https://github.com/scoverage/sbt-scoverage-samples/blob/master/build.gradle#L9
and project dependencies are declared separately:
https://github.com/scoverage/sbt-scoverage-samples/blob/master/build.gradle#L29
I don't know Gradle, but I wonder if there is a way to remove dependencies/gradle section from the project at all? Can different version of scalac-scoverage-plugin be specified somewhere in buildscript/dependencies if required and proper version of scalac-scoverage-runtime selected and added to project's scoverage-scoped dependencies automatically by the plugin?

[gslowikowski]

What I would like to achieve is default configuration to be as simple as possible.

[maiflai]

I agree with the sentiment - my concern is that there appeared to be no consistent way to determine the version of scala that is being used in a gradle project.

I'll check again later, but I thought the part of the Scala plugin that does this was private.

sbt supports the %% syntax, does maven expose the major version? Does maven support cross-compilation?

[gslowikowski]

Maven does not expose anything, plugin is responsible for finding Scala version:
https://github.com/scoverage/scoverage-maven-plugin/blob/scoverage-maven-plugin-1.0.2/src/main/java/org/scoverage/plugin/SCoveragePreCompileMojo.java#L202
and resolving required -plugin and -runtime artifact versions:
https://github.com/scoverage/scoverage-maven-plugin/blob/scoverage-maven-plugin-1.0.2/src/main/java/org/scoverage/plugin/SCoveragePreCompileMojo.java#L253

[maiflai]

Ah - yes, I don't want to release a new version of the gradle plugin when they start releasing 2.12 in a few months time.

[gslowikowski]

This is design choice.

[gslowikowski]

Looking at my code now, I could add scalaMainVersion parameter with empty default value. Current resolution mechanism would work only if there is no value specified by user.

[gslowikowski]

There is scalaBinaryVersion property in SBT build.
Plugin adds dependencies, the code is very simple:
https://github.com/scoverage/sbt-scoverage/blob/master/src/main/scala/scoverage/ScoverageSbtPlugin.scala#L93
-plugin and -runtime dependencies version is constant value now (https://github.com/scoverage/sbt-scoverage/blob/master/src/main/scala/scoverage/ScoverageSbtPlugin.scala#L14, but could be easily parametrized (added to ScoverageKeys object) if needed.

[maiflai]

The gradle code would functionally be a carbon copy of the maven code, but in physically fewer lines.

I do object to every scala plugin implementing version discovery themselves.

The current implementation is from a time when there was only one jar, and I felt that it did not add value to lock the user to precise maven coordinates.

I'll look at adding a public scala binary version to the gradle scala plugin, with the aim being to provide similar information as SBT.

[ckipp01]

So for now I think I'm going to actually close this. I've read through the thread and I believe I understand the issues raised, but I don't think creating a CLI is the way to go. Honestly, I'd probably be a better idea to provide a Java interface to write reports instead.

If this is something that people still want to talk about and explore we can definitely do this, but it's been 6 years since there has been any movement here.