softwaremill / sbt-softwaremill   2.0.18

Apache License 2.0 GitHub

A sane set of default build settings

Scala versions: 2.12
sbt plugins: 1.0


Build Status Maven Central

A sane set of common build settings.


For each project where you'd like to use the build settings, add some or all of the following your project/plugins.sbt file:

addSbtPlugin("com.softwaremill.sbt-softwaremill" % "sbt-softwaremill-common" % "2.0.18")
addSbtPlugin("com.softwaremill.sbt-softwaremill" % "sbt-softwaremill-publish" % "2.0.18")
addSbtPlugin("com.softwaremill.sbt-softwaremill" % "sbt-softwaremill-extra" % "2.0.18")
addSbtPlugin("com.softwaremill.sbt-softwaremill" % "sbt-softwaremill-browser-test-js" % "2.0.18")

Now you can add the appropriate settings in your build.sbt, e.g.:

import com.softwaremill.SbtSoftwareMillCommon.commonSmlBuildSettings

lazy val commonSettings = commonSmlBuildSettings ++ Seq(
  // your settings, which can override some of commonSmlBuildSettings

Each dependency provides a choice of settings:

// common - compiler flags
import com.softwaremill.SbtSoftwareMillCommon.commonSmlBuildSettings

// publish
import com.softwaremill.Publish.ossPublishSettings

// extra - use all or choose
lazy val extraSmlBuildSettings =
  dependencyUpdatesSettings ++  // check dependency updates on startup (max once per 12h)

// downloads the appropriate chrome/gecko driver for testing scala.js using scalajs-env-selenium and sets the jsenv
import com.softwaremill.SbtSoftwareMillBrowserTestJS.{browserChromeTestSettings, browserGeckoTestSettings}

sbt-softwaremill-common comes with:

sbt-softwaremill-publish comes with:

sbt-softwaremill-extra comes with:

Sonatype setup

By default, the plugins use the new host for releasing to Sonatype. If your project isn't yet migrated, you'll need to add the following to your root project settings:

sonatypeCredentialHost := ""

Releasing your library

sbt-softwaremill-publish exposes a default configuration suitable for releasing open source libraries. The release process is broken into two steps:

  1. local: sbt release. This sbt command prepares the next release: asks about the version, updates the version in the docs & readme, commits the changes and finally asks the user to push the changes. Your, docs and doc directory will be parsed for "[organization]" %(%) "artifactId" % "someVersion" and that version value will be bumped.
  2. remote: sbt ci-release. This sbt command should be run on GH actions, triggered when a new tag is pushed. It publishes the artifacts to sonatype, and invokes repository release.

To setup the remote part, follow the guide on sbt-ci-release. You can also take a look at this project's .github/workflows/ci.yml.

You might need to explicitly set the sonatype profile name:

val commonSettings = ossPublishSettings ++ Seq(
  sonatypeProfileName := "com.example"

Releasing sbt-softwaremill

sbt-softwaremill release process is setup on GH Actions. This plugin uses itself to publish binaries to oss-sonatype.

Note for migrating from sbt-softwaremill 1.x series

You should remove version.sbt file as it's no longer used, and it may disrupt the release process. In the 2.x series the version is deduced from git tags and the current state using

Moreover, a number of bundled plugins are removed, which aren't available for Scala3 and would cause build problems