27

I've written an sbt plugin called sbt-jumi which implements sbt integration for Jumi. Right now the sbt-jumi plugin depends on the current Jumi release.

Here is the relevant line from the plugin's build.sbt:

libraryDependencies += "fi.jumi" % "jumi-launcher" % "0.5.376"

And a user of the plugin would add this to his project/plugins.sbt file:

addSbtPlugin("fi.jumi.sbt" % "sbt-jumi" % "0.1.0")

Now let's say that Jumi 0.6.400 is released and it's backward compatible. How can a user of the sbt-jumi plugin configure it to use Jumi 0.6.400, without me having to release a new version of the plugin?

Here is how to do it in Maven. But how to do it in sbt?

Esko Luontola
  • 73,184
  • 17
  • 117
  • 128

2 Answers2

39

Overriding the dependencies of plugins happens the same way as overriding normal dependencies, except that the configuration must be entered into project/plugins.sbt. Overriding dependencies is explained in Library Management. Here is a summary:

If the version you wish to use is greater than the dependency that you would get transitively, sbt will use the larger version by default. You may change the conflict manager to change the default behavior - for example this will create an error on conflict:

conflictManager := ConflictManager.strict

In other words, this in project/plugins.sbt would work:

libraryDependencies += "fi.jumi" % "jumi-launcher" % "0.6.400"

You may check your plugin dependencies using reload plugins and then show update. It should now show the older version as "(EVICTED)".

If the version you wish to use is lower than the default dependency, then you will need to override differently. One way is to force the dependency:

libraryDependencies += "fi.jumi" % "jumi-launcher" % "0.4.350" force()

Another way is to use the dependencyOverrides setting:

dependencyOverrides += "fi.jumi" % "jumi-launcher" % "0.4.350"

The difference between the two methods is that overriding doesn't introduce a direct dependency. I don't think the difference matters for plugins, but for published artifacts it has some differences.

Esko Luontola
  • 73,184
  • 17
  • 117
  • 128
  • Here is an issue I got and want to share : day 0 : current online published version of the plugin `0.3` | day1 : I publish locally my in-development plugin with version `0.4` and reference this plugin with a local repository | day 2 : the plugin is published with version `0.4` on internet official repo | day 3 : my plugin does not do what I expect anymore because sbt load both plugins but decide to take the one from internet. To workaround the issue I had to change my version to `0.5` and then it worked. – Maxence Jun 24 '14 at 15:31
  • How can I completely _exclude_ a dependency of an sbt plugin? – mkurz Feb 20 '20 at 09:10
  • 1
    OK found out myself: Add `excludeDependencies` in `build.sbt`, see https://github.com/mkurz/coursier-excludedependencies-sbtplugin/blob/master/build.sbt#L7-L11. However be aware if you use coursier there is a bug so it does not work yet: https://github.com/coursier/coursier/issues/1590 – mkurz Feb 20 '20 at 11:51
1

If the dependency you want to override is itself also an sbt plugin, then the answer is slightly different.

All these changes are in the project/plugins.sbt

If the plugin is a newer version then you can simply add it like normal and the automatic dependency resolution should pick the newer version, but if you need it to be an earlier version, then you need to add this:

dependencyOverrides += {
  val sbtV = (pluginCrossBuild / sbtBinaryVersion).value
  val scalaV = (update / scalaBinaryVersion).value
  val dependency = "fi.jumi" % "jumi-sbt" % "{version}"
  sbt.Defaults.sbtPluginExtra(dependency, sbtV, scalaV)
}

this just replicates what addSbtPlugin is doing under the hood.

Henry Parker
  • 171
  • 1
  • 5