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.
useJCenter can be set to true to re-include it, as the first external resolver to find library dependencies. #2217/#2467 by @eed3si9n
withInterProjectFirst to the update option, which is enabled by default. When set to true, inter-project resolver will be prioritized above all resolvers and Ivy cache. #1827 by @eed3si9n
withLatestSnapshots so it handles modules without an artifact. This flag will be enabled by default.
#1514/#1616/#2313 by @eed3si9n
-J<flag> options to the local Java compiler. #1968/#2272 by @Duhemm
sbt.global.autoimport flag is true. #2120/#2399 by @timcharper
publishMavenStyle is true, update task warns when it sees intransitive dependencies, which do not translate to Maven. #2127 by @jsuereth
Def.settings, which facilitates mixing settings with seq of settings. See below.
Logger.Null public. #2094 by @pdalpra
Append.Sequence instance for List to allow +=/++= on developers setting. #2107/#2114 by @pdalpra
sealed from the typeclasses in Append. #2322 by @dwijnand
localIfFile to MavenRepository, to force artifacts to be copied to the cache. #2172 by @dwijnand
Resolver.bintrayIvyRepo(owner, repo). #2285 by @dwijnand
-J options. sbt/sbt-launcher-package#105
sbt.Execute. #2302/#2303 by @jrudolph
updateClassifiers downloading updated snapshot sources and docs.
#1750/sbt/ivy#17/#2163/sbt/ivy#18/#2186 by @dwijnand
updateClassifiers on Ivy modules without default configuration.
#2264 by @eed3si9n/@Duhemm
ListBuffer#readOnly. #2095 by @adriaanm
tasks and settings command. #2192 by @DavidPerezIngeniero
javac by always failing if the local Java compiler reported errors. #2228/#2271 by @Duhemm
JavaErrorParser to parse non-compile-errors #2256/#2272 by @Duhemm
sbt-ivy-snapshots repository to resolve nightly builds. @eed3si9n
compileLate. #2453 by @retronym
SBT_OPTS. sbt/sbt-launcher-package#101 by @eed3si9n
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.
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.
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
)
Using Def.settings it is now possible to nicely define settings as such:
val modelSettings = Def.settings(
sharedSettings,
libraryDependencies += foo
)
sbt 0.13.10 did not happen due a bug that was found after the artifact was published.
crossScalaVersions default value is fixed back to the older 0.12.x behavior. See below for details.
withSources() or withJavadoc(). See below for details.
retrieveManaged related improvements. See below for details.
-= and --= for settings and tasks, which are the opposites of += and ++=. #1922 by @dwijnand
inThisBuild, similar to inConfig, to allow specifying multiple settings in ThisBuild scope. #1847/#1989 by @dwijnand
forceUpdatePeriod key, that takes values of Option[FiniteDuration]. If set, a full update will occur after that amount of time without needing to explicitly run the update task. By @ajsquared
ForkError.getMessage() to include exception’s original name. #2028 by @kamilkloch
inspect actual. #1651/#1990 by @dwijnand
testOnly/testQuick with -, for example -MySpec.
#1970 by @matthewfarwell
Extracted.runInputTask helper to assist with imperatively executing input tasks. #2006 by @jroper
distinct method on PathFinder to distinctName. #1973 by @eed3si9n
distinctPath method on PathFinder. #1973 by @eed3si9n
maven-metadata.xml. See below.
help command. #1900/#1940 by @DavidPerezIngeniero
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.
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
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
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
@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.
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:
SNAPSHOT related issues.
sbt 0.13.9 fixes this by relaxing the Maven compatiblity check, so it will read maven-metadata.xml. #2075 by @eed3si9n
IvyPlugin by default (-Dsbt.root.ivyplugin=true will revert this behavior). #1871/#1869 by @dwijnand
evicted will display all evictions (including the ones not suspected of binary incompatibility). #1615 by @eed3si9n
--depth 1 for git clone. #1787 by @xuwei-k
compilerReporter is fed to javac during incremental compilation. #1542 by @jsuereth
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
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
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:
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!
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
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
)
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:
previousCompile: This task returns the previously persisted Analysis object for this project.
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.
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.
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.
Compile rather than every configuration if no master configuration is found. #1586 by @jsuereth
Here are examples:
val x, y = project // BAD
val x = project //
val y = project // GOOD
~/.sbt/repositories. #1579 by @copumpkin
file URLs. #1618 by @jsuereth
TextAnalysisFormat. #1572 by @Duhemm
developers key. #1590 by @jedesah
scalaHome/scalaInstance and running tests. #1584 by @jsuereth
set every. #1591/#1430 by @cunei
HttpClient resolver when httpclient is on the classpath. #1602 by @jsuereth
maven-metadata.xml file (common given the divergence in
Maven 3 and Ivy 2), we attempt to use LastModified timestamp in lieu of “published” timestamp.
#1611/#1618 by @jsuereth
ChainResolver and Maven repositories. #1611/#1618 by @jsuereth
Resolver’s url method dropping descriptorOptional and skipConsistencyCheck. #1621 by @tmandke
useLatestSnapshot on updateOptions to default to false. Reverts chain resolver to previous behavior. #1683 by @jsuereth
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
Maven local repository is now resolved from the first of:
<localRepository/> element in ~/.m2/settings.xml
<localRepository/> element in $M2_HOME/conf/settings.xml, or
~/.m2/repository if neither of those configuration elements exist
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.
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)
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.
ThisProject used to resolve to the root project in a build even when it’s place in subproj/build.sbt. sbt 0.13.6 fixes it to resolve to the sub project. #1194/#1358 by @dansanduleac
newer command in scripted. #1419 by @jroper
inc.Analysis.empty also defaults to the one compatible with name hashing. #1546 by @gkossakowski
projectDependencies. #1366/#1367 by @dansanduleac
build.sbt to be used from sbt shell. #1059/#1456
Resolver.jcenterRepo and Resolver.bintrayRepo(owner, repo) to add Bintray easier. #1405 by @evgeny-goldin
plugin command. #1416/#1426 by @lpiepiora
scala-jar to the list of jar artifacts recognized by CustomPomParser. #1400 by @dpratt
-Xfatal-warnings. #1477 by @puffnfresh
set comamnd #1486 @jsuereth
++ scala version setting. #856/#1489 by @jsuereth
Scope.parseScopedKey. #1384 by @eed3si9n
build.sbt errors causing ArrayIndexOutOfBoundsException due to invalid source in position. #1181 by @eed3si9n
http.proxyPassword showing up in launcher’s update.log. #670 by @eed3si9n
1.1+. #1275 by @eed3si9n
NullPointerError in tab completion by FileExamples. #1530 by @eed3si9n
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.
sbt 0.13.6 now allows enablePlugins and disablePlugins to be written directly in build.sbt. #1213/#1312 by @jsuereth
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
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)
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)
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 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.
sbt.Plugin deprecated in favor of sbt.AutoPlugin
testResultLogger is now configured.
JUnitXmlReportPlugin which generates junit-xml-reports for all tests.
-Dsbt.task.forcegc=true).
