Short answer: don’t put these files in the source control repository as you can “generate” them (and this is even more true if you don’t need them, if they are annoying, if they can break others environment). I personally use the following values for svn:ignore: target *~ *.log .classpath .project *.ipr *.iws *.iml .settings
For a similar case I used in assembly.sbt: run in Compile <<= Defaults.runTask(fullClasspath in Compile, mainClass in (Compile, run), runner in (Compile, run)) and now the ‘run’ task uses all the libraries, including the ones marked with “provided”. No further change was necessary. Update: @rob solution seems to be the only one working on latest … Read more
Yes this is entirely possible. Nothing to setup really, a small build.sbt file should do the trick, something like: organization := “your.group.id” name := “Your project” version := “1.0-SNAPSHOT” libraryDependencies ++= Seq( <any normal jar deps> ) And run sbt package from the command line.
Go to Preference -> Build, Execution, Deployment -> SBT -> check “Use SBT shell for build and import” -> Press OK You can now refresh SBT projects and it should work . if you want, you could uncheck “Use SBT shell for build and import” and it will also work
xsbt (0.10+, including the latest 0.13.7) Change scalaVersion in build.sbt to whatever Scala version your project should be using – see .sbt build definition. scalaVersion := “2.10.1” sbt: As mentioned in RunningSBT, you can: You can temporarily switch to another version of Scala using ++<version>. This version does not have to be listed in your … Read more
The problem is that you are mixing Scala 2.11 and 2.10 artifacts. You have: scalaVersion := “2.11.8” And then: libraryDependencies += “org.apache.spark” % “spark-streaming_2.10” % “1.4.1” Where the 2.10 artifact is being required. You are also mixing Spark versions instead of using a consistent version: // spark 1.6.1 libraryDependencies += “org.apache.spark” %% “spark-core” % “1.6.1” … Read more
(Disclaimer: I maintain sbt-assembly) sbt-assembly sbt-assembly creates a fat JAR – a single JAR file containing all class files from your code and libraries. By evolution, it also contains ways of resolving conflicts when multiple JARs provide the same file path (like config or README file). It involves unzipping of all library JARs, so it’s … Read more
I fixed by deleting the <project base>/project/target directory, as suggested here: https://youtrack.jetbrains.com/issue/SCL-15160#focus=streamItem-27-3373132.0-0 On Terminal: rm -r project/target
Try this libraryDependencies += “com.acme.common” % “commonclass” % “1.0” from “file:///Users/bwong/git/perf-tools/commonclass/target/scala-2.11/commonclass_2.11-1.0.jar” I “sbt package” the common classproject and then just add that library dependency in my build.sbt in the dependent projects. Thanks to http://flummox-engineering.blogspot.com/2014/06/sbt-use-jar-file-for-librarydependencies.html for this hack.
Read Scopes for the full explanation. I’ll quote relevant parts: There are three scope axes: The subproject axis The dependency configuration axis The task axis Scoping by project axis If you put multiple projects in a single build, each project needs its own settings. That is, keys can be scoped according to the project. The … Read more