sbt 0.13.5+ Technology Previews 

sbt 0.13.5+ releases of sbt are technology previews of what’s to come to sbt 1.0 with enhancements like auto plugins, launcher enhacements for sbt server, defined in the sbt-remote-control project, and other necessary API changes.

These releases maintain binary compatibility with plugins that are published against sbt 0.13.0, but add new features in preparation for sbt 1.0. The tech previews allow us to test new ideas like auto plugins and performance improvements on dependency resolution; the build users can try new features without losing the existing plugin resources; and plugin authors can gradually migrate to the new plugin system before sbt 1.0 arrives.

sbt 0.13.17 

Improvements 

Bug fixes 

Internal 

sbt 0.13.16 

Fixes with compatibility implications 

Improvements 

Bug fixes 

sbt-cross-building 

@jrudolph’s sbt-cross-building is a plugin author’s plugin. It adds cross command ^ and sbtVersion switch command ^^, similar to + and ++, but for switching between multiple sbt versions across major versions. sbt 0.13.16 merges these commands into sbt because the feature it provides is useful as we migrate plugins to sbt 1.0.

To switch the sbtVersion in pluginCrossBuild from the shell use: 

^^ 1.0.0-RC2

Your plugin will now build with sbt 1.0.0-RC2 (and its Scala version 2.12.2).

If you need to make changes specific to a sbt version, you can now include them into src/main/scala-sbt-0.13, and src/main/scala-sbt-1.0, where the binary sbt version number is used as postfix.

To run a command across multiple sbt versions, set: 

crossSbtVersions := Vector("0.13.15", "1.0.0-RC2")

Then, run: 

^ compile

#3133 by @eed3si9n

Eviction warning presentation 

sbt 0.13.16 improves the eviction warning presetation.

Before: 

[warn] There may be incompatibilities among your library dependencies.
[warn] Here are some of the libraries that were evicted:
[warn]  * com.google.code.findbugs:jsr305:2.0.1 -> 3.0.0
[warn] Run 'evicted' to see detailed eviction warnings

After: 

[warn] Found version conflict(s) in library dependencies; some are suspected to be binary incompatible:
[warn]
[warn]      * com.typesafe.akka:akka-actor_2.12:2.5.0 is selected over 2.4.17
[warn]          +- de.heikoseeberger:akka-log4j_2.12:1.4.0            (depends on 2.5.0)
[warn]          +- com.typesafe.akka:akka-parsing_2.12:10.0.6         (depends on 2.4.17)
[warn]          +- com.typesafe.akka:akka-stream_2.12:2.4.17 ()       (depends on 2.4.17)
[warn]
[warn] Run 'evicted' to see detailed eviction warnings

#3202 by @eed3si9n

Improvements and bug fixes to the startup messages 

sbt writes out the sbt.version in project/build.properties if it is missing. sbt 0.13.16 fixes the logging when it happens by using the logger.

We encourage the use of the sbt shell by running sbt, instead of running sbt compile from the terminal repreatedly. The sbt shell keeps the JVM warm, and there is a significant performance improvement gained for your compilation. The startup message that we added in sbt 0.13.15 was a bit too aggressive, so we are toning it down in 0.13.16. It will only be triggered for sbt compile, and it can also be supressed with suppressSbtShellNotification := true.

#3091/#3097/#3147 by @dwijnand

sbt 0.13.15 

Fixes with compatibility implications 

Improvements 

Bug fixes 

Maven version range improvement 

Previously, when the dependency resolver (Ivy) encountered a Maven version range such as [1.3.0,) it would go out to the Internet to find the latest version. This would result to a surprising behavior where the eventual version keeps changing over time even when there’s a version of the library that satisfies the range condition.

Starting sbt 0.13.15, some Maven version ranges would be replaced with its lower bound so that when a satisfactory version is found in the dependency graph it will be used. You can disable this behavior using the JVM flag -Dsbt.modversionrange=false.

#2954 by @eed3si9n

Offline installation 

sbt 0.13.15 adds two new repositories called “local-preloaded-ivy” and “local-preloaded” that point to ~/.sbt/preloaded/. The purpose for the repositories is to preload them with sbt artifacts so the installation of sbt will not require access to the Internet.

This also improves the startup time of sbt when you first run it since the resolution happens off of a local-preloaded repository.

#2993/#145 by @eed3si9n

Notes 

No changes should be necessary to your project definition and all plugins published for sbt 0.13.{x|x<14} should still work.

See Migrating from sbt 0.12.x for details on the old operator deprecation.

Special thanks to the contributors for making this release a success. According to git shortlog -sn --no-merges v0.13.13..0.13.15, compared to 0.13.13, there were 64 (non-merge) commits, by eleven contributors: Eugene Yokota, Dale Wijnand, Guillaume Martres, Jason Zaugg, Lars Hupel, Petro Verkhogliad, Eric Richardson, Claudio Bley, Haochi Chen, Paul Draper, Ashley Mercer. Thank you!

sbt 0.13.14 

sbt 0.13.14 did not happen due a bug that was found after the artifact was published.

sbt 0.13.13 

Fixes with compatibility implications 

Improvements 

Bug fixes 

new command and templateResolverInfos 

sbt 0.13.13 adds a new command, which helps create new build definitions. The new command is extensible via a mechanism called the template resolver. A template resolver pattern matches on the passed in arguments after new, and if it’s a match it will apply the template.

As a reference implementation, template resolver for Giter8 is provided. For instance: 

sbt new eed3si9n/hello.g8

will run eed3si9n/hello.g8 using Giter8.

#2705 by @eed3si9n

Synthetic subprojects 

sbt 0.13.13 adds support for AutoPlugins to define subprojects programmatically, by overriding the extraProjects method: 

import sbt._, Keys._

object ExtraProjectsPlugin extends AutoPlugin {
  override def extraProjects: Seq[Project] =
    List("foo", "bar", "baz") map generateProject

  def generateProject(id: String): Project =
    Project(id, file(id))
      .settings(
        name := id
      )
}

In addition, subprojects may be derived from an existing subproject by overriding derivedProjects: 

import sbt._, Keys._

object DerivedProjectsPlugin extends AutoPlugin {
  // Enable this plugin by default
  override def requires: Plugins = sbt.plugins.CorePlugin
  override def trigger = allRequirements

  override def derivedProjects(proj: ProjectDefinition[_]): Seq[Project] =
    // Make sure to exclude project extras to avoid recursive generation
    if (proj.projectOrigin != ProjectOrigin.DerivedProject) {
      val id = proj.id + "1"
      Seq(
        Project(id, file(id))
          .enablePlugins(DatabasePlugin)
      )
    }
    else Nil
}

#2532/#2717/#2738 by @eed3si9n

Deprecate old sbt 0.12 DSL 

The no-longer-documented operators <<=, <+=, and <++= and tuple enrichments are deprecated, and will be removed in sbt 1.0.

Generally, 

task3 <<= (task1, task2) map { (t1, t2) => println(t1 + t2); t1 + t2 }

should migrate to 

task3 := {
  println(task1.value + task2.value)
  task1.value + task2.value
}

Except for source generators, which requires task values: 

sourceGenerators in Compile <+= buildInfo

This becomes: 

sourceGenerators in Compile += buildInfo.taskValue

Another exception is input task: 

run <<= docsRunSetting

This becomes: 

run := docsRunSetting.evaluated

See Migrating from sbt 0.12.x for more details.

#2716/#2763/#2764 by @eed3si9n and @dwijnand

sbt 0.13.12 

Fixes with compatibility implications 

Improvements 

Bug fixes 

sbt 0.13.11 

Fixes with compatibility implications 

Improvements 

Bug fixes 

Configurable Scala compiler bridge 

sbt 0.13.11 adds scalaCompilerBridgeSource setting to specify the compiler brigde source. This allows different implementation of the bridge for Scala versions, and also allows future versions of Scala compiler implementation to diverge. The source module will be retrieved using library management configured by bootIvyConfiguration task.

#2106/#2197/#2336 by @Duhemm

Dotty awareness 

sbt 0.13.11 will assume that Dotty is used when scalaVersion starts with 0.. The built-in compiler bridge in sbt does not support Dotty, but a separate compiler bridge is being developed at smarter/dotty-bridge and an example project that uses it is available at smarter/dotty-example-project.

#2344 by @smarter

Inter-project dependency tracking 

sbt 0.13.11 adds trackInternalDependencies and exportToInternal settings. These can be used to control whether to trigger compilation of a dependent subprojects when you call compile. Both keys will take one of three values: TrackLevel.NoTracking, TrackLevel.TrackIfMissing, and TrackLevel.TrackAlways. By default they are both set to TrackLevel.TrackAlways.

When trackInternalDependencies is set to TrackLevel.TrackIfMissing, sbt will no longer try to compile internal (inter-project) dependencies automatically, unless there are no *.class files (or JAR file when exportJars is true) in the output directory. When the setting is set to TrackLevel.NoTracking, the compilation of internal dependencies will be skipped. Note that the classpath will still be appended, and dependency graph will still show them as dependencies. The motivation is to save the I/O overhead of checking for the changes on a build with many subprojects during development. Here’s how to set all subprojects to TrackIfMissing. 

lazy val root = (project in file(".")).
  aggregate(....).
  settings(
    inThisBuild(Seq(
      trackInternalDependencies := TrackLevel.TrackIfMissing,
      exportJars := true
    ))
  )

The exportToInternal setting allows the dependee subprojects to opt out of the internal tracking, which might be useful if you want to track most subprojects except for a few. The intersection of the trackInternalDependencies and exportToInternal settings will be used to determine the actual track level. Here’s an example to opt-out one project: 

lazy val dontTrackMe = (project in file("dontTrackMe")).
  settings(
    exportToInternal := TrackLevel.NoTracking
  )

#2266/#2354 by @eed3si9n

Def.settings 

Using Def.settings it is now possible to nicely define settings as such: 

val modelSettings = Def.settings(
  sharedSettings,
  libraryDependencies += foo
)

#2151 by @dwijnand

sbt 0.13.10 

sbt 0.13.10 did not happen due a bug that was found after the artifact was published.

sbt 0.13.9 

Fixes with compatibility implications 

Improvements 

Bug fixes 

crossScalaVersions default value 

As of this fix crossScalaVersions returns to the behaviour present in 0.12.4 whereby it defaults to what scalaVersion is set to, for example if scalaVersion is set to "2.11.6", crossScalaVersions now defaults to Seq("2.11.6").

Therefore when upgrading from any version between 0.13.0 and 0.13.8 be aware of this new default if your build setup depended on it.

#1828/#1992 by @dwijnand

POM files no longer include certain source and javadoc jars 

When declaring library dependencies using the withSources() or withJavadoc() options, sbt was also including in the pom file, as dependencies, the source or javadoc jars using the default Maven scope. Such dependencies might be erroneously processed as they were regular jars by automated tools

#2001/#2027 by @cunei

retrieveManaged related improvements 

sbt 0.13.9 adds retrieveManagedSync key that, when set to true, enables synchronizing retrieved to the current build by removed unneeded files.

It also adds configurationsToRetrieve key, that takes values of Option[Set[Configuration]]. If set, when retrieveManaged is true only artifacts in the specified configurations will be retrieved to the current build.

#1950/#1987 by @ajsquared

Cached resolution fixes 

On a larger dependency graph, the JSON file growing to be 100MB+ with 97% of taken up by caller information. To make the matter worse, these large JSON files were never cleaned up.

sbt 0.13.9 filters out artificial or duplicate callers, which fixes OutOfMemoryException seen on some builds. This generally shrinks the size of JSON, so it should make the IO operations faster. Dynamic graphs will be rotated with directories named after yyyy-mm-dd, and stale JSON files will be cleaned up after few days.

sbt 0.13.9 also fixes a correctness issue that was found in the earlier releases. Under some circumstances, libraries that shouldn’t have been evicted was being evicted. This occured when library A1 depended on B2, but a newer A2 dropped the dependency, and A2 and B1 are also is in the graph. This is fixed by sorting the graph prior to eviction.

#2030/#1721/#2014/#2046/#2097 by @eed3si9n

Force GC 

@cunei in #1223 discovered that sbt leaks PermGen when it creates classloaders to call Scala Compilers. sbt 0.13.9 will call GC on a set interval (default: 60s). It will also call GC right before cross building. This behavior can diabled using by setting false to forcegc setting or sbt.task.forcegc flag.

#1773 by @eed3si9n

Maven compatibility fix 

To resolve dynamic versions such as SNAPSHOT and version ranges, the dependency resolution engine queries for the list of available versions. For Maven repositories, it was supposed read maven-metadata.xml first, but because sbt customizes the repository layout for cross building, it has been falling back to screen scraping of the Apache directory listing. This problem surfaced as:

sbt 0.13.9 fixes this by relaxing the Maven compatiblity check, so it will read maven-metadata.xml. #2075 by @eed3si9n

sbt 0.13.8 

Changes with compatibility implications 

Improvements 

Fixes 

Rolling back XML parsing workaround 

sbt 0.13.7 implemented natural whitespace handling by switching build.sbt parsing to use Scala compiler, instead of blank line delimiting. We realized that some build definitions no longer parsed due to the difference in XML handling. 

val a = <x/><y/>
val b = 0

At the time, we thought adding parentheses around XML nodes could work around this behavior. However, the workaround has caused more issues, and since then we have realized that this is a compiler issue SI-9027, so we have decided to roll back our workaround. In the meantime, if you have consecutive XML elements in your build.sbt, enclose them in <xml:group> tag, or parentheses. 

val a = <xml:group><x/><y/></xml:group>
val b = 0

#1765 by @ajozwik

Cross-version support for Scala sources 

When crossPaths setting is set to true (it is true by default), sbt 0.13.8 will include src/main/scala-<scalaBinaryVersion>/ to the Compile compilation in addition to src/main/scala. For example, it will include src/main/scala-2.11/ for Scala 2.11.5, and src/main/scala-2.9.3 for Scala 2.9.3. #1799 by @indrajitr

Maven resolver plugin 

sbt 0.13.8 adds an extension point in the dependency resolution to customize Maven resolvers. This allows us to write sbt-maven-resolver auto plugin, which internally uses Eclipse Aether to resolve Maven dependencies instead of Apache Ivy.

To enable this plugin, add the following to project/maven.sbt (or project/plugin.sbt the file name doesn’t matter): 

addMavenResolverPlugin

This will create a new ~/.ivy2/maven-cache directory, which contains the Aether cache of files. You may notice some file will be re-downloaded for the new cache layout. Additionally, sbt will now be able to fully construct maven-metadata.xml files when publishing to remote repositories or when publishing to the local ~/.m2/repository. This should help erase many of the deficiencies encountered when using Maven and sbt together.

Notes and known limitations:

#1793 by @jsuereth

Project-level dependency exclusions 

sbt 0.13.8 adds experimental project-level dependency exclusions: 

excludeDependencies += "org.apache.logging.log4j"
excludeDependencies += "com.example" %% "foo"

In the first example, all artifacts from the organization "org.apache.logging.log4j" are excluded from the managed dependency. In the second example, artifacts with the organization "com.example" and the name "foo" cross versioned to the current scalaVersion are excluded.

Note: This feature currently does not translate to pom.xml!

#1748 by @eed3si9n

Sequential tasks 

sbt 0.13.8 adds a new Def.sequential function to run tasks under semi-sequential semantics. Here’s an example usage: 

lazy val root = project.
  settings(
    testFile := target.value / "test.txt",
    sideEffect0 := {
      val t = testFile.value
      IO.append(t, "0")
      t
    },
    sideEffect1 := {
      val t = testFile.value
      IO.append(t, "1")
      t
    },
    foo := Def.sequential(compile in Compile, sideEffect0, sideEffect1, test in Test).value
  )

Normally sbt’s task engine will reorder tasks based on the dependencies among the tasks, and run as many tasks in parallel (See Custom settings and tasks for more details on this). Def.sequential instead tries to run the tasks in the specified order. However, the task engine will still deduplicate tasks. For instance, when foo is executed, it will only compile once, even though test in Test depends on compile. #1817/#1001 by @eed3si9n

Nicer ways of declaring project settings 

Now a Seq[Setting[_]] can be passed to Project.settings without the needs for “varargs expansion”, ie. : _*

Instead of: 

lazy val foo = project settings (sharedSettings: _*)

It is now possible to do: 

lazy val foo = project settings sharedSettings

Also, Seq[Setting[_]] can be declared at the same level as individual settings in Project.settings, for instance: 

lazy val foo = project settings (
  sharedSettings,
  version := "1.0",
  someMoreSettings
)

#1902 by @dwijnand

Bytecode Enhancers 

sbt 0.13.8 adds an extension point whereby users can effectively manipulate java bytecode (.class files) before the incremental compiler attempts to cache the classfile hashes. This allows libraries like ebean to function with sbt without corrupting the compiler cache and rerunning compile every few seconds.

This splits the compile task into several subTasks:

  1. previousCompile: This task returns the previously persisted Analysis object for this project.
  2. compileIncremental: This is the core logic of compiling Scala/Java files together. This task actually does the work of compiling a project incrementally, including ensuring a minimum number of source files are compiled. After this method, all .class files that would be generated by scalac + javac will be available.
  3. manipulateByteCode: This is a stub task which takes the compileIncremental result and returns it. Plugins which need to manipulate bytecode are expected to override this task with their own implementation, ensuring to call the previous behavior.
  4. compile: This task depends on manipulateBytecode and then persists the Analysis object containing all incremental compiler information.

Here’s an example of how to hook the new manipulateBytecode key in your own plugin: 

manipulateBytecode in Compile := {
  val previous = (manipulateBytecode in Compile).value
  doManipulateBytecode(previous)  // Note: This must return a new Compiler.CompileResult with our changes.
}

See #1714 for the full details of the implementation.

sbt 0.13.7 

Fixes with compatibility implications 

Here are examples: 

val x, y = project // BAD
val x = project    // 
val y = project    //  GOOD

Improvements 

Bug fixes 

Natural whitespace handling 

Starting sbt 0.13.7, build.sbt will be parsed using a customized Scala parser. This eliminates the requirement to use blank line as the delimiter between each settings, and also allows blank lines to be inserted at arbitrary position within a block.

This feature can be disabled, if necessary, via the -Dsbt.parser.simple=true flag.

This feature was contributed by Andrzej Jozwik (@ajozwik), Rafał Krzewski (@rkrzewski) and others at @WarsawScala inspired by Typesafe’s @gkossakowski organizing multiple meetups and hackathons on how to patch sbt with the focus on this blank line issue. Dziękujemy! #1606

Custom Maven local repository location 

Maven local repository is now resolved from the first of:

If more Maven settings are required to be recovered, the proper thing to do is merge the two possible settings.xml files, then query against the element path of the merge. This code avoids the merge by checking sequentially.

#1589/#1600 by @topping

Circular dependency 

By default circular dependencies are warned, but they do not halt the dependency resolution. Using the following setting, circular dependencies can be treated as an error. 

updateOptions := updateOptions.value.withCircularDependencyLevel(CircularDependencyLevel.Error)

#1601 by @eed3si9n

Cached resolution (minigraph caching) 

sbt 0.13.7 adds a new experimental update option called cached resolution, which replaces consolidated resolution: 

updateOptions := updateOptions.value.withCachedResolution(true)

Unlike consolidated resolution, which only consolidated subprojects with identical dependency graph, cached resolution create an artificial graph for each direct dependency (minigraph) for all subprojects, resolves them independently, saves them into json file, and stiches the minigraphs together.

Once the minigraphs are resolved and saved as files, dependency resolution turns into a matter of loading json file from the second run onwards, which should complete in a matter of seconds even for large projects. Also, because the files are saved under a global ~/.sbt/0.13/dependency (or what’s specified by sbt.dependency.base flag), the resolution result is shared across all builds.

Breaking graphs into minigraphs allows partial resolution results to be shared, which scales better for subprojects with similar but slightly different dependencies, and also for making small changes to the dependencies graph over time. See documentation on cached resolution for more details.

#1631 by @eed3si9n

sbt 0.13.6 

Fixes with compatibility implications 

Improvements 

Bug fixes 

HTTPS related changes 

Thanks to Sonatype, HTTPS access to Maven Central Repository is available to public. This is now enabled by default, but if HTTP is required for some reason the following system properties can be used: 

-Dsbt.repository.secure=false

Java.net Maven 2 repository, Typesafe repository, and sbt Plugin repository also defaults to HTTPS.

#1494 by @rtyley, #1536 by @benmccann, and #1541 by @eed3si9n.

enablePlugins/disablePlugins 

sbt 0.13.6 now allows enablePlugins and disablePlugins to be written directly in build.sbt. #1213/#1312 by @jsuereth

Unresolved dependencies error 

sbt 0.13.6 will try to reconstruct dependencies tree when it fails to resolve a managed dependency. This is an approximation, but it should help you figure out where the problematic dependency is coming from. When possible sbt will display the source position next to the modules: 

[warn]  ::::::::::::::::::::::::::::::::::::::::::::::
[warn]  ::          UNRESOLVED DEPENDENCIES         ::
[warn]  ::::::::::::::::::::::::::::::::::::::::::::::
[warn]  :: foundrylogic.vpp#vpp;2.2.1: not found
[warn]  ::::::::::::::::::::::::::::::::::::::::::::::
[warn] 
[warn]  Note: Unresolved dependencies path:
[warn]      foundrylogic.vpp:vpp:2.2.1
[warn]        +- org.apache.cayenne:cayenne-tools:3.0.2
[warn]        +- org.apache.cayenne.plugins:maven-cayenne-plugin:3.0.2 (/foo/some-test/build.sbt#L28)
[warn]        +- d:d_2.10:0.1-SNAPSHOT

#528/#1422/#1447 by @eed3si9n

Eviction warnings 

sbt 0.13.6 displays eviction warnings when it resolves your project’s managed dependencies via update task. Currently the eviction warnings are categorized into three layers: scalaVersion eviction, direct evictions, and transitive evictions. By default eviction warning on update task will display only scalaVersion evictin and direct evictions.

scalaVersion eviction warns you when scalaVersion is no longer effecitive. This happens when one of your dependency depends on a newer release of scala-library than your scalaVersion. Direct evctions are evictions related to your direct dependencies. Warnings are displayed only when API incompatibility is suspected. For Java libraries, Semantic Versioning is used for guessing, and for Scala libraries Second Segment versioning (second segment bump makes API incompatible) is used.

To display all eviction warnings with caller information, run evicted task. 

[warn] There may be incompatibilities among your library dependencies.
[warn] Here are some of the libraries that were evicted:
[warn]     * com.typesafe.akka:akka-actor_2.10:2.1.4 -> 2.3.4 (caller: com.typesafe.akka:akka-remote_2.10:2.3.4,
org.w3:banana-sesame_2.10:0.4, org.w3:banana-rdf_2.10:0.4)

#1200/#1467 by @eed3si9n

Latest SNAPSHOTs 

sbt 0.13.6 adds a new setting key called updateOptions for customizing the details of managed dependency resolution with update task. One of its flags is called lastestSnapshots, which controls the behavior of the chained resolver. Up until 0.13.6, sbt was picking the first -SNAPSHOT revision it found along the chain. When latestSnapshots is enabled (default: true), it will look into all resolvers on the chain, and compare them using the publish date.

The tradeoff is probably a longer resolution time if you have many remote repositories on the build or you live away from the severs. So here’s how to disable it: 

updateOptions := updateOptions.value.withLatestSnapshots(false)

#1514 by @eed3si9n

Consolidated resolution 

updateOptions can also be used to enable consolidated resolution for update task. 

updateOptions := updateOptions.value.withConsolidatedResolution(true)

This feature is specifically targeted to address Ivy resolution is beging slow for multi-module projects #413. Consolidated resolution aims to fix this issue by artificially constructing an Ivy dependency graph for the unique managed dependencies. If two subprojects introduce identical external dependencies, both subprojects should consolidate to the same graph, and therefore resolve immediately for the second update. #1454 by @eed3si9n

sbt 0.13.5 

sbt 0.13.5 is a technology preview of what’s to come to sbt 1.0 with enhancements like auto plugins and the necessary APIs changes and launcher for “sbt as a server.”, defined in the sbt-remote-control project.

Next Page > sbt 0.13.0 - 0.13.2

Contents

sbt Reference Manual
      2. sbt 0.13.5+ Technology Previews
Documentation Download Get Involved Source code sbt on Twitter

Community Support

StackOverflow
lightbend-icon

Commercial Support

Lightbend Subscription Training Consulting