[SBT documentation] says
Put settings in a .sbt file in a project that isn't checked into version control, such as <project>/local.sbt. sbt combines the settings from multiple .sbt files, so you can still have the standard <project>/build.sbt and check that into version control.
However, if two .sbt files define the same setting, which one wins?
As of sbt 0.13.8, we might load *.sbt files in alphabetical order, but I don't think we have documented this behavior to be true. Thus, it's likely an implementation detail at this point.
We do promise:
setting order within the same file
plugin dependencies specified by auto plugins
settings loaded by auto plugin, then settings in *.sbt
So I would recommend using auto plugin if possible. Another way of de-prioritizing a setting is to scope in ThisBuild. You can either use an auto plugin or some project to define:
organization in ThisBuild := "com.example"
It's alphabetic ordering:
a.sbt
name := "a"
b.sbt
name := "b"
Test:
% sbt 'show name'
[info] Loading global plugins from /Users/dnw/.dotfiles/.sbt/0.13/plugins
[info] Loading project definition from /Users/dnw/Desktop/t-2015-04-18.1551/project
[info] Set current project to b (in build file:/Users/dnw/Desktop/t-2015-04-18.1551/)
[info] b
Related
after changing the sbt.version in the build.properties to 1.3.x, i've found out that the resolved.xml.xml files, which were created after running sbt compile are not created anymore. i'm using those files to re-create the project's structure and dependencies tree.
is there any equivalent to those files in the new SBT version?
yes, i'm familiar with sbt-dependency-graph plugin, but i want to avoid using external solution.
You can disable the integrated coursier to get the old behaviour back:
ThisBuild / useCoursier := false
I'm working on an SBT project that has to be built with the options like:
-Xmx2G -Xss256M -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled
This means that every new developer has to read the readme and assign the options to SBT_OPTS in bash profile or put them in the sbtopts file. Similarly, this has to be configured on Jenkins and this applies to all the projects (so if someone wants to use -XX:+UseG1GC with other projects it becomes an issue). Is it possible to specify the required options in the build file itself? This seems logical to me, as the options are project-specific and without them, you cannot build the project.
Create a .sbtopts file at the root of the build with contents:
-J-Xmx2G
-J-Xss256M
-J-XX:+UseConcMarkSweepGC
-J-XX:+CMSClassUnloadingEnabled
I am using some sbt plugins on a project and I would like to know which are their versions from sbt console.
I can type plugins which list the plugins but do not present their versions.
I want to do it from the sbt console, I do not want to inspect some plugins.sbt file or similar somewhere.
When you use plugins command, you see references to the plugins as they are defined in the Scala code. A single artifact can contain many plugins. Those artifacts with plugins have versions and here's how you can see them.
First load the metaproject: reload plugins
Then check dependencies: libraryDependencies
Go back to your project: reload return
You can define an alias for this in your ~/.sbt/<version>/global.sbt:
addCommandAlias("pluginsVersions", "; reload plugins ; libraryDependencies ; reload return")
It's not perfect, the output is noisy and not formatted nicely, but it's something you can get out of the box.
I'm using sbt 0.10 to build a Scala project using just a build.sbt file instead of a full configuration.
Every time I start sbt it gives me the messages as follows:
[info] Set current project to default-ee699e (in build file:/Users/.../project/plugins/)
[info] Set current project to default-8febe7 (in build file:/Users/.../)
I did set the name and mainClass settings in the build.sbt file, so I don't know what I need to set to get the project names default-XXXX go away.
EDIT: the answer given below is correct in that this is cosmetic. If you switch to a full configuration of sbt, then it uses that project's name as opposed to default-XXXX however.
The message can be a bit misleading, it's not saying that you must "set the curent project", it's telling you what it's doing.
It sets the current project to the plugins folder, does it's stuff (compile, etc.), then sets the current project to your actual build folder and does it's thing once again.
You don't need to set anything else.
I'm new to SBT, using version 1.0 and a custom repository, and I've set the "retrieveManaged" flag mentioned here, but it seems that SBT only downloads the directly requested JARs, but not any of the JARs upon which those JARs depend. And yes, the repository is using the customary default format described in the answers here (though SBT/Ivy doesn't seem capable of retrieving snapshots, either, but that's a separate problem, I expect). The repository does not require any kind of authentication, FYI.
Here's a slightly generified version of my built.sbt file:
name := "MyProject"
organization := "com.myorg"
version := "0.1"
scalaVersion := "2.9.0"
scalacOptions += "-deprecation"
retrieveManaged := true
resolvers += Resolver.url("myorg", url("http://host.com//content/groups/public"))
libraryDependencies += "com.myorg" % "otherproject" % "1.0"
fork in run := true
The requested "otherproject" JAR file loads fine, but SBT/Ivy seems to have no interest in opening up its POM and downloading the other JARs it needs to operate. This seems like it should be a fairly basic function (Maven does it, for example) but I have no idea how to convince SBT/Ivy to do so. (And the documentation assures us that SBT is, in fact, supposed to do this: "By default, these declarations fetch all project dependencies, transitively".)
I believe I must be doing something wrong, but have no idea -- given how simple and vanilla this basic configuration is -- what it could be.
Standard, Maven-style repositories are declared like:
resolvers += "myorg" at "http://host.com/content/groups/public"
More details are at the Library Management page you linked to and on the Resolvers page.
Typically, one only uses Resolver.url when specifying non-standard layouts.