don't add to libraryDependencies unless enabled

[fommil]

I've noticed that the scoverage plugin and runtime support is added to libraryDependencies even if coverage is not enabled. Would it be hard to not do it this way? And only add the jars when coverage is enabled?

Currently, scoverage gets added as a provided dependency on Maven Central to all projects that might use it (plus it shows up as a real dependency in IDEs)

[sksamuel]

It should actually never be added in a package. And only added when you
invoke it.

On 3 January 2016 at 11:29, Sam Halliday notifications@github.com wrote:

I've noticed that the scoverage plugin and runtime support is added to
libraryDependencies even if coverage is not enabled. Would it be hard to
not do it this way? And only add the jars when coverage is enabled?

Currently, scoverage gets added as a provided dependency on Maven Central
to all projects that might use it (plus it shows up as a real dependency in
IDEs)

—
Reply to this email directly or view it on GitHub
#153.

[fommil]

this is our setup https://github.com/ensime/ensime-server/blob/master/project/EnsimeBuild.scala

it looks like here the libraryDependencies are being mutated as soon as the plugin is loaded https://github.com/scoverage/sbt-scoverage/blob/master/src/main/scala/scoverage/ScoverageSbtPlugin.scala#L29

rather than here, when it is enabled,

https://github.com/scoverage/sbt-scoverage/blob/master/src/main/scala/scoverage/ScoverageSbtPlugin.scala#L52

[heartsucker]

Hey, adding to the discussion. On sbt 0.13.8 with scoverage 1.3.3, we get this added the generated pom for projects with scoverage disabled and not running the coverage command.

<dependency>
    <groupId>org.scoverage</groupId>
    <artifactId>scalac-scoverage-runtime_2.11</artifactId>
    <version>1.1.1</version>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>org.scoverage</groupId>
    <artifactId>scalac-scoverage-plugin_2.11</artifactId>
    <version>1.1.1</version>
    <scope>provided</scope>
</dependency>

I'm pretty sure there shouldn't be any scoverage jars added to the project.

[fommil]

yes, this is exactly the same thing.

[rklaehn]

I also noticed this when looking at the pom for cats-kernel here https://github.com/non/cats/pull/806#issuecomment-171791057

[fommil]

that was sneaky! I didn't even see you fix this 😄

Will there be a release soon?

[sksamuel]

Lol. Do you want to confirm it before I do?

On 21 January 2016 at 20:49, Sam Halliday notifications@github.com wrote:

that was sneaky! I didn't even see you fix this [image: 😄]

Will there be a release soon?

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

[fommil]

do you publish snapshots?

[fommil]

I'll test locally

[fommil]

ok, I need you to publish a snapshot. classic mismatched pgp config stuff...

java.lang.ClassCastException: Cannot cast com.typesafe.sbt.SbtPgp$ to sbt.Plugin
    at java.lang.Class.cast(Class.java:3369)

I personally put all my gpg setup in my global settings to avoid this nonsense.

[fommil]

• https://github.com/fommil/dotfiles/blob/master/.sbt/0.13/plugins/plugins.sbt#L5
• https://github.com/fommil/dotfiles/blob/master/.sbt/0.13/global.sbt#L8

[sksamuel]

What's the advantage of that one vs the one I use ?

On 21 January 2016 at 21:12, Sam Halliday notifications@github.com wrote:

https://github.com/fommil/dotfiles/blob/master/.sbt/0.13/plugins/plugins.sbt#L5

https://github.com/fommil/dotfiles/blob/master/.sbt/0.13/global.sbt#L8

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