Any distribution example for Akka application using SBT and sbt-native-packager? I managed to use akka-sbt-plugin to package the entire application into a runnable server for distribution. Now, I am struggling to do the same with this plugin because akka-sbt-plugin is been replaced by sbt-native-packager. Thanks
Here is an example https://gist.github.com/tobym/3665514fde79eaab8724
Basically, just include addSbtPlugin("com.typesafe.sbt" % "sbt-native-packager" % "0.8.0-M1")
in project/plugins.sbt, and in build.sbt import com.typesafe.sbt.SbtNativePackager._ and NativePackagerKeys._.
Then run rpm:packageBin (or another option, such as debian...this depends on your deploy target) and fill in the missing settings in build.sbt until it works. For rpm, you'll need to have the rpm tools available. On mac, you can get this with sudo port install rpm.
Related
In my Play project I notice that build.properties has sbt version addSbtPlugin("com.typesafe.play" % "sbt-plugin" % "2.6.12")
and build.properties has sbt.version=0.13.15.
1) Why are there two enteries?
2) What is the difference between them
3) Should their versions be different?
There is a difference between SBT proper and SBT plugin. Play Framework is an SBT plugin. The version of SBT is specified in project/build.properties:
sbt.version=0.13.15
whilst the version of Play SBT plugin is specified in project/plugins.sbt:
addSbtPlugin("com.typesafe.play" % "sbt-plugin" % "2.6.12")
Scala Play SBT plugin (PlayScala) is enabled in build.sbt like so:
lazy val root = (project in file(".")).enablePlugins(PlayScala)
SBT plugins enrich build definitions with additional useful tasks, commands, settings, and dependencies. Here are some examples from Play SBT plugin:
object PlayKeys {
val playDefaultPort = SettingKey[Int]("playDefaultPort", "The default port that Play runs on")
val playDefaultAddress = SettingKey[String]("playDefaultAddress", "The default address that Play runs on")
val playRunHooks = TaskKey[Seq[PlayRunHook]]("playRunHooks", "Hooks to run additional behaviour before/after the run task")
...
So for example to change the default port that Play runs on we can define in build.sbt:
PlayKeys.playDefaultPort := 9009
Note when upgrading SBT version we need to make sure it is compatible with corresponding Play SBT plugin. For example, to use Play with SBT 1 we need to update Play sbt-plugin to 2.6.6.
SBT plugin best practice artifact naming convention encurages the following naming scheme:
sbt-$projectname
For example, sbt-scoverage, sbt-buildinfo, sbt-release, sbt-assembly, however Play named it sbt-plugin, which arguably can be confusing.
I was wondering if SBT has something similar to the Gradle Wrapper?
I would like to use it on a CI server without having to install SBT first.
The documentation mentions a sbt-launcher, but that seems to be geared towards running actual application instead of builds.
Yes, sbt-extras is a bash script that you can commit to your repository to act like the gradle wrapper.
The sbt-extras project is centered around a stand-alone script called sbt which can be directly used to run sbt without having it on the machine first.
The script has logic to determine the proper version of sbt for the project, download the correct version of the sbt jar, and then run the tasks through sbt.
If you copy the sbt script into your project, you can simply call it — from your CI server, locally, or wherever — to run sbt tasks without needing sbt installed separately.
I have a Play project that I would like to deploy via RPM. I'm trying to use SBT to build the RPM, on CentOS, using the sbt-native-packager RPM plugin.
At the end I gt the rpm package.
But it stored in directory under %appname%/target/rpm
How can I use my own path for rpm buildroot tree?
Say, for example /home/build/buildroot
Sbt-native-packager version in use 0.8.0.
The simple (rpm config centric) answer is to configure %_topdir in ~/.rpmmacros before invoking rpmbuild. SBT may be adding additional complexities.
I have an SBT application that is using JavaCV on Windows.
My build.sbt brings in JavaCV and its dependencies using:
classpathTypes += "maven-plugin"
libraryDependencies += "org.bytedeco" % "javacv" % "0.9"
This pulls JavaCV and its dependents (JavaCPP), but it isn't pulling the JAR with the platform specific libraries (opencv-windows-x86_64.jar). This allows me to build, but I get "UnsatisfiedLinkError: no jniopencv_core in java.library.path"
Based on http://www.warski.org/blog/2014/01/using-javacv-with-sbt I also tried
libraryDependencies += "org.bytedeco" % "javacv" % "0.9" classifier "windows-x86_64"
SBT fails trying to resolve that dependency because it is looking for http://repo1.maven.org/maven2/org/bytedeco/javacv/0.9/javacv-0.9-windows-x86_64.jar which doesn't exist.
If I copy opencv-windows-x86_64.jar to the lib directory then everything works, but that defeats the point of using a dependency manager.
Does anyone know how to make SBT properly resolve the platform specific jars for JavaCV 0.9?
Using the -Dplatform.dependencies=true option on the command line should do the trick!
I wrote an SBT plugin to make OpenCV dependency handling (yes, including platform dependencies) a one liner: https://github.com/lloydmeta/sbt-opencv
Simply add this to your project/plugins.sbt:
addSbtPlugin("com.beachape" % "sbt-opencv" % "1.4")
I'm interested in building an RPM package for sbt 0.12.3 that meets the Fedora packaging guidelines. In order to do this, I'll need to be able to build sbt itself against libraries that were built from source and installed via RPM packages.
Java packages in Fedora that use Ivy are able to resolve RPM-installed artifacts by disabling network resolvers and resolving all packages from /usr/share/java/[artifact].[ext] -- see here for an example.
I think I understand how to override default resolvers in sbt using a boot properties file, but this is where I run in to a problem: if I set the Ivy directory to /usr/share/java, sbt expects to be able to publish artifacts to this directory (not merely to look for existing artifacts there), which I don't want it to do (both in general and for this specific case of RPM building). If I specify file:///usr/share/java as a proxy location (following Mark's instructions below), sbt will fail (citing the absence of ivy.xml in that location).
I am able to find locally-installed dependencies by modifying project/p.sbt to point to explicit URLs (e.g. "org.jsoup" % "jsoup" % "1.7.1" from "file:///usr/share/java/jsoup.jar"), but this doesn't work for scala and the scala library (and is obviously not the right thing to do in general).
How can I build sbt against (and only against) locally-installed, RPM-managed system Scala and libraries?