According to the sbt documentation:
The current recommendation is to use Multi-project .sbt build definition.
When I try to implement this as per the documentation's example, sbt no longer recognizes the sbt-assembly and sbteclipse plugins I added in:
./project/assembly.sbt
./project/plugins.sbt
It does work when I revert to a bare .sbt build definition.
I'm assuming the explanation is something to do with scoping, or some additional lines I need in my build.sbt file.
Does anyone have the explanation? I don't think this is in the documentation. At least not anywhere that I can find it. If I'm wrong, please point me to the relevant section. Thanks!
Related
I am not sure how to split the build.sbt file in a Play project. Usually in the Play projects I have seen only one build.sbt file, but the project I am referring to have multiple build files in addition to the build.sbt file like:
build.checkstyle.sbt
build.findbugs.sbt
build.junit.sbt
I am not sure if they have split the build.sbt file or is it something else all together. Can anybody help me understand what is happening here?
One more thing is I know what are the purpose of these files like the checkstyle file is used for code style checking and the junit file is for the unit testing. These functions are working perfectly fine, but what I am struggling to understand is how/where did they configure it. I mean these files are not imported by the base build.sbt file so how is the configuration done?
This is just how sbt works. It scans your project for .sbt files, not only a build.sbt file. From sbt docs:
Any time files ending in .scala or .sbt are used, naming them build.sbt and Build.scala are conventions only. This also means that multiple files are allowed.
So, basically, at the mentioned project, people decided that it would be better to split the settings in different files. There is nothing special to do and sbt will handle that for you. Another example is Playframework itself:
https://github.com/playframework/playframework/tree/master/framework
See how it have a build.sbt and a version.sbt files. This is also just a convention so that you can configure the project version at a separated file (which is understood by some sbt plugins, like sbt-release).
As known, in golang, go get dir/... would find out and download all dependencies of package specified by dir.
Then in scala, does sbt provide similar function? So that we don't need to add dependencies into build file?
I am afraid the scala sbt doesn't provide the exact kind of feature you are looking. However, sbt does provide several ways to automate the process of downloading dependencies. The closest technique related to your use case would be using ivy configuration and setting files.
You can read about that here:
http://www.scala-sbt.org/0.12.4/docs/Detailed-Topics/Library-Management.html
I am almost sure I read/saw somewhere that latest sbt versions allow me to place Scala-version specific sources in particular directories so they would be picked up depending on scalaVersion automatically, without having to fiddle around with unmanagedSourceDirectories and creating a source filtering setting. Like
src/main/scala/worksInAllVersions.scala
src/main/scala_211???/myTraitForScala211.scala
src/main/scala_210???/myTraitForScala210.scala
Is this so? The docs don't mention anything.
This seems to have been added in this pull request into sbt 0.13.8. The directories must be named
src/main/scala-2.10/
src/main/scala-2.11/
This is a very simple question, but I surprisingly havn't gotten an answer for it yet.
Simply put, in most non trivial SBT projects you will have a plugins.sbt file that contains plugins that are required to run your project (like a web container plugin if your SBT project is a website). However in the same file (plugins.sbt), plugins which have nothing to do with actually running your project (such as ensime/intellij/eclipse project generators) are also typically placed in plugins.sbt
I have seen this behavior for many SBT projects which are placed into github
This ideally speaking is not the correct way to do things, ideally plugins which have nothing to do with actually running/compiling your project should be in a separate file which is put into a .gitignore
What is the idiomatic SBT way of dealing with this (I assume it should be something that consists of having 2 separate plugins.sbt files, one with actual project plugins and the other with IDE generators and whatnot)
You can install plugins globally by placing them in ~/.sbt/0.13/plugins/. .sbt or .scala files located here are loaded for every project that you have.
You can also use addSbtPlugin() in a .sbt file to add other plugins.
Check out http://www.scala-sbt.org/release/docs/Getting-Started/Using-Plugins.html
Disclaimer: I'm scala beginner. All defaults works nice for me, but whenever I want to have custom layout/build I run into a problem.
So, as part of my build I need to pull .war(web app) from project A and .jar(jetty launcher) from project B into some directory of project C(tanuki service wrapper).
Can anybody please provide an an example how to do this in the most effective way.
Not sure if it works with war files, but for making jars locally available you could use sbt's publish-local command. Say you have an sbt project "mylibrary" and another sbt project "mymain". If you locally publish "mylibrary.jar", you can add it as a dependency to "mymain" just like you add any other sbt-managed dependency, i.e., by adding a line such as
libraryDependencies += "foo.bar.com" %% "mylibrary" % "0.1-SNAPSHOT"
to the build.sbt of "mymain".
If that is not possible you might want to write an sbt plugin/command that copies the files into a given directory. I don't have experience with extending sbt, so I can't help with that, but other stackoverflowers surely can :-)
EDIT: (addressing a comment by the OP)
No, I don't have a particular Sbt tutorial. If I need help I turn to the usual suspects, the wiki, the mailing list, Stackoverflow, Sbt's source code. Sbt has an IO package which offers a copyFile method, which, according to this thread, comes in handy. Searching for 'copying files' on the mailing list also yields other results that might help you.