How do I prepend to an SBT setting?
++= appends. What prepends?
(Background: I want to put different resolvers before Typesafe for my Play project.)
You could set the value to be the given resolver + the old ones, that way the old values all go the back of the search queue.
For build.sbt:
resolvers := ("releases" at "https://oss.sonatype.org/service/local/staging/deploy/maven2") +: resolvers.value
For Build.scala try something like:
lazy val root = Project("myproject", file("."))
.settings(otherSettings: _*)
.settings(resolvers := ("releases" at "https://oss.sonatype.org/service/local/staging/deploy/maven2") +: resolvers.value)
Related
I have a set of .proto files (protobuf) which I generate java from using scalapb. I also have in the same sbt 2 sub-projects, one is scalaVersion 2.11 compatible (can't upgrade it to 2.12 due to missing packages) and the other one is scala 2.12.
I created a sub-project to hold my proto, and by default 2.12 is used and my 2.12 sub-project can use it, but my 2.11 can't.
I set the crossScalaVersions to 2.11/2.12, I compiled my project with both, which passed, but then even then I was unable to get the 2.11 sub-project to find that code.
I am "wondering" if that is something supported, or if there is a track I could use a single location to hold my .proto yet have my 2 sub-projects using the same sbt file use those.
lazy val scala212 = "2.12.13"
lazy val scala211 = "2.11.12"
lazy val supportedScalaVersion = List(scala212, scala211)
ThisBuild / scalaVersion := scala212
lazy val root = (project in file("."))
.aggregate(proto, subproject1, subproject2)
.settigns(
crossScalaVersions := Nil,
publish / skip := true
)
lazy val proto = project
.settings(
crossScalaVersions := supportedScalaVersions,
name := "proto",
libraryDependencies += "com.trueaccord.scalapb" %% "scalapb-runtime" % com.trueaccord.scalapb.compiler.Version.scalapbVersion % "protobuf",
PB.targets in Compile := Seq(
scalapb.gen(grpc = false) -> (sourceManaged in Compile).value / "protobuf"
)
)
lazy val subproject1 = project
.dependsOn(proto)
lazy val subproject2 = project
.settings(
scalaVersion := scala211
)
.dependsOn(proto)
So, from the above, if I do sbt "+ proto" I can compile both versions. If I do sbt subproject1/compile it works too. Using sbt subproject2/compile fails indicating that it cannot find the 2.11:proto jar file.
Either, I would like the above somehow to work nicely, or any other trick that I could generate the code from the same proto location but within subproject1/subproject2 would be appreciated.
You could try the sbt-projectmatrix plugin:
https://github.com/sbt/sbt-projectmatrix
The idea is to have separate sbt subprojects for the different Scala versions, so you can simply reference the relevant subproject when calling dependsOn.
I think this plugin is going to end up in sbt some day as it's a much better solution in general than the current built-in stateful cross compilation support, and it's developed by Eugene Yokota, who is also an sbt developer.
Using sbt 0.13.5, when opening the project in IntelliJ, there is a warning message
~\myproject\project\Build.scala:5: trait Build in package sbt is
deprecated: Use .sbt format instead
The content of the Build.scala is
import sbt._
object MyBuild extends Build {
lazy val root = Project("MyProject", file("."))
.configs(Configs.all: _*)
.settings(Testing.settings ++ Docs.settings: _*)
}
The Appendix: .scala build definition and the sbt documentation is rather overwhelming.
How to merge my existing Build.scala to build.sbt? Would appreciate any direction to doc/tutorial/examples.
Rename Build.scala to build.sbt and move it up one directory level, so it's at the top rather than inside the project directory.
Then strip out the beginning and end, leaving:
lazy val root = Project("MyProject", file("."))
.configs(Configs.all: _*)
.settings(Testing.settings ++ Docs.settings: _*)
That's the basics.
Then if you want to add more settings, for example:
lazy val root = Project("MyProject", file("."))
.configs(Configs.all: _*)
.settings(
Testing.settings,
Docs.settings,
name := "MyApp",
scalaVersion := "2.11.8"
)
You don't need the :_* thing on sequences of settings anymore in sbt 0.13.13; older versions required it.
The migration guide in the official doc is here: http://www.scala-sbt.org/0.13/docs/Migrating-from-sbt-012x.html#Migrating+from+the+Build+trait
I have a multi-SBT-project in IntellJ Idea. My SBT file in the root dir looks like this:
name := "PlayRoot"
version := "1.0"
lazy val shapeless_learn = project.in(file("shapeless_learn")).dependsOn(common)
lazy val scalaz_learn = project.in(file("scalaz_learn")).dependsOn(common)
lazy val common = project.in(file("common"))
lazy val root = project.in(file(".")).aggregate(common, shapeless_learn, scalaz_learn)
scalaVersion := "2.11.7"
Then I have folders for each of the projects: ./common, ./shapeless_learn, ./scalaz_learn and each has its own build.sbt there. But for some reason I require to put in each of the subproject build.sbt files the line scalaVersion := "2.11.7".
If I forget to do that, the build fails with the message:
Error:Unresolved dependencies: common#common_2.10;0.1-SNAPSHOT: not found
See complete log in ...
For some reason if I do not specify that my scala version is 2.11.7, sbt falls back to 2.10 and tries to find common project that is built for 2.10 which I do not have.
I always keep forgetting adding scalaVersion := "2.11.7" to the newly created project and it keeps bugging me. I also would prefer sbt generating build.sbt with some default data, but instead it requires me not to forget to create it manually.
Is there any way I could set the single scala version for all projects and sub-projects in a single place? I figured that I could add a separate lazy val commonSettings = Seq { scalaVersion := "2.11.7" } in a root definition. And for each lazy val project definition I should add in the end .settings(commonSettings). This is nice, but still doesn't look beautiful enough - I should do this for every project definition. Is there a better way?
Is there any way I could create a template for a newly created project, so when I just put line lazy val newProject = ..., it will put an appropriate build.sbt file there with the contents I want?
Use
scalaVersion in ThisBuild := "2.11.7"
in the root build.sbt.
I am new to SBT and trying to build a project. My Build.scala looks like
lazy val ec = project.in(file("."))
.settings(commonSettings: _*)
.settings(name := "ec")
.aggregate(ahka, currentLogProcessor, main)
lazy val currentLogProcessor = project.in(file("currentLogProcessor"))
.settings(commonSettings: _*)
.settings(name := "currentlogprocessor")
.settings(
libraryDependencies += "com.myorg.util" % "LP" % "0.18.0-SNAPSHOT" % "provided"
)
lazy val main = project
.settings(commonSettings: _*)
.settings(name := "main")
When SBT refreshes in IntelliJ, I see following
As you could see, even if the settings looks same for currentLogProcessor and main, the project structure is very very different.
project inside currentLogProcessor looks good but project under main is layer with project and src
What is the issue here? How can I remove the layers of project inside project?
Thanks
Your projects ec and main share the same folder. Remove main or ec, or change "in file" for one of them.
lazy val main = project in file("another_path") ...
The answer by #ka4eli is correct, but I'd like to point out few issues with the build definition that can make understanding it so much painful.
Defining top-level aggregate project
lazy val ec = project.in(file("."))
.settings(commonSettings: _*)
.settings(name := "ec")
.aggregate(ahka, currentLogProcessor, main)
You don't need it whatsoever as it's defined automatically anyway - you're just repeating what sbt does implicitly. Just remove it from the build and add build.sbt with the following:
commonSettings
Use build.sbt for a project's build definition
lazy val currentLogProcessor = project.in(file("currentLogProcessor"))
.settings(commonSettings: _*)
.settings(name := "currentlogprocessor")
.settings(
libraryDependencies += "com.myorg.util" % "LP" % "0.18.0-SNAPSHOT" % "provided"
)
By default, lazy val's name is used to call a project project macro should point to, i.e. no need for in(file("currentLogProcessor")). The same applies to the name setting - you're using all-lowercase name that may or may not be needed.
Use build.sbt under currentLogProcessor directory to have the same effect:
name := "currentlogprocessor"
commonSettings
libraryDependencies += "com.myorg.util" % "LP" % "0.18.0-SNAPSHOT" % "provided"
It's that simple.
Apply the rules to the main project.
Have fun with sbt = it's so simple that people hardly accept it and mess up build definitions on purpose to claim otherwise :)
When I am using play framework, every time I've changed the code, it will take effect automatically by re-compile the code.
However, when I'm using sbt to run a project without play-plugin, it won't take effect.
I'm wondering if there were a way to make sbt project hot swap the changed code.
My build.sbt is as below:
version in ThisBuild := "1.0-SNAPSHOT"
scalaVersion in ThisBuild := "2.11.6"
lazy val `frontend` = (project in file("frontend")).
enablePlugins(PlayScala).
enablePlugins(DockerPlugin).
settings(
name := "frontend",
libraryDependencies ++= Dependencies.frontend
).dependsOn(`api`).aggregate(`api`)
lazy val `backend` = (project in file("backend")).
enablePlugins(JavaAppPackaging).
enablePlugins(DockerPlugin).
settings(
name := "backend",
libraryDependencies ++= Dependencies.backend ++ Seq(cache, ws)
).dependsOn(`api`).aggregate(`api`)
lazy val `api` = (project in file("api")).
settings(
name := "api",
libraryDependencies += ws
)
And what I have configured in intellij idea is like below as a sbt task(I can't post images by now):
"project backend" ~run
However, every time I've changed the code in backend, It won't take effect after I've call backend from the frontend.
I'm wondering how I can solve the problem. Thanks for your guys' help.
You can have sbt automatically recompiling any changes by invoking it like this:
sbt ~compile
If you use ~run, on every change the changeed classes will be compiled and project rerun again.
If it does not work, you might explain more about your project and structure.
Open two SBT window.
The one run ~compile, and another run ~run.
Hope it will be help.