simplify settings for deb only build with sbt native packager - scala

I am trying to package my scala main app code as a .deb file. the app will only run on an ubuntu machine, so I do not really care about windows etc.
Currently, I am struggling to find the most easiest way to compile the .deb using the simpliest settings. Let's assume I have a simple object Kernel extends App scala file in my src folder that should be bundled inlcuding the jardependencies.
my current scala based debian settings for the project are:
import com.typesafe.sbt.SbtNativePackager._
import NativePackagerKeys.
val debSettings = mapGenericFilesToLinux ++ linuxSettings ++ debianSettings ++ Seq(
name in Debian := "my-app",
version in Debian := "0.1-version",
mainClass := Some("Kernel"),
packageSummary := "",
target := new java.io.File("target"),
packageDescription := "my app",
packageDescription := "my app desciption",
NativePackagerKeys.normalizedName := "normalizedName",
maintainer := "my name",
sourceDirectory := new java.io.File("./src"),
debianPackageDependencies in Debian ++= Seq("openjdk-7-jre"),
debianPackageRecommends in Debian ++= Seq(),
linuxPackageMappings in Debian ++= Seq() ,
debianMaintainerScripts ++=Seq())
the debian:package-bincall works and a deb is created but no binaries/jars are copied into the deb so i'm obviously missing some configuration. i know that there are still missing linuxPackageMappings etc but i'm wondering if there is an easier configuration for the compilation? using packageArchetype.java_server forces me to include so many not-used variables for windows etc. I want to avoid this.
Any suggestion how to simplify the settings + mappings for a deb-only build?

You can just pull in the settings that are relevant to you from:
https://github.com/sbt/sbt-native-packager/blob/master/src/main/scala/com/typesafe/sbt/packager/archetypes/JavaServerApplication.scala#L24
and
So, this should be something like:
import com.typesafe.sbt.packager.archetypes._
packagerSettings
mapGenericMappingsToLinux
JavaAppPackaging.settings
JavaServerAppPackaging.debianSettings
caveat the correct imports. Let's cover what each of these do:
packagerSettings adds the basic "flow" of the packager tasks, but does not configure any of the files or settings
mapGenericMappingsToLinux is the hook which will take everything configured in mappings in Universal and attempt to make it linux friendly for linux packages.
JavaAppPackaging.settings will take your build definition, and automatically fill out the mappings in Universal configuration with defaults for your application.
JavaServerAppPackaging.debianSettings adds additional settings specifically for debian such that the bundled default application can be started as a server.
One of the goals of the plugin is to allow you the flexibility to use any of these "mappings" and get default behavior or override. It's just not well documented how. I hope this helps!

Related

Loading external settings in build.sbt

I'm trying to add an sbt plugin to a play application.
The plugin requires some configuration since it needs to connect to a database. These are the settings that the plugin requires in the build.sbt file:
jooqOptions := Seq("jdbc.driver" -> "com.mysql.jdbc.Driver",
"jdbc.url" -> "jdbc:mysql://localhost:3306/fnord",
"jdbc.user" -> "fnord",
"jdbc.password" -> "fnord",
"generator.database.name" -> "org.jooq.util.mysql.MySQLDatabase",
"generator.database.inputSchema" -> "fnord",
"generator.target.packageName" -> "com.myproject.jooq")
Since the user and password will depent on the specific machine on which i deploy the app, i would like to load them from somewhere where each user can assign the user and password himself.
How do i do that?
I've solved it using the accepted solution from:
How get application version in play framework and build.sbt
I've added this to my build.sbt:
import com.typesafe.config._
val conf = ConfigFactory.parseFile(new File("conf/application.conf")).resolve()
version := conf.getString("app.version")
and in my application.conf:
app.version="0.2-SNAPSHOT"
One way would be to read them from an environment variable, another to have a config file of some kind in a predefined path that you load and read in your sbt project.
Since the sbt config is scala code you can for example use sys.env to read environment variables.
You can find the scaladoc for sys.env here

CoffeeScript and sbt-concat

I'm having trouble concatenating and fingerprinting all the CoffeeScript files in Play application. Everything works fine for JavaScript files with build.sbt like this one
pipelineStages := Seq(concat, digest)
Concat.groups := Seq(
"javascripts/app.js" -> group(((sourceDirectory in Assets).value / "javascripts") * "*.js")
)
But when sourceDirectory is changed to resourcesManaged that supposedly contains compiled CoffeeScript files sbt-concat doesn't pick them up.
sbt-coffeescript, and all other official source task plugins, don't put their files in resourcesManaged in Assets, but instead their own sub-directory in target/web/<taskname>. They scope the resourcesManaged setting to their main task, in this case this means resourcesManaged in (Assets, coffeescript) and resourcesManaged in (TestAssets, coffeescript).
When you run sbt coffeescript you can see the files are output to target/web/coffeescript/main. You can verify this by running show web-assets:coffeescript::resourceManaged from the sbt console.

What are the options to set base packaged directory for a package using sbt-native-packager?

I am trying to build a Debian package using sbt-native-packager as described in this build.sbt.
I set appName using
val appName = "megamgateway"
in project/Build.scala.
All works well. It is just that the contents are stored in /usr/share/megamgateway.
I'd like to have the contents under /usr/share/megam/gateway.
The only way I could find is to use
linuxPackageMapping
as shown here.
Before following along, I'd like to know about other approaches.
You could try to add to your project settings
name := "gateway"
defaultLinuxInstallLocation := "/usr/share/megam/"

How can I configure Scalatra (sbt) to find the webapp folder in a different source folder than "main" [duplicate]

By default, Scalatra expects the "webapp" directory to be at src/main/webapp. How could that be changed to, e.g., content/doc-root?
sbt allows for customizing its default directories using something like the following:
scalaSource <<= (baseDirectory)(_ / "src")
So I assume it's just a matter of knowing the right "configuration key" to use...
#Kelsey Gilmore-Innis has the right answer, but since it's not accepted let's break it, break it, break it down.
First, I'm assuming you're following Getting started guide to install Scalatra using g8. Hopefully the same version I just got.
g8 scalatra/scalatra-sbt
What that g8 template did was to set up an sbt 0.13 build which uses scalatra-sbt 0.3.2 plugin:
addSbtPlugin("org.scalatra.sbt" % "scalatra-sbt" % "0.3.2")
This plugin internally uses JamesEarlDouglas/xsbt-web-plugin 0.4.0 to do the webapp-related settings.
xsbt-web-plugin 0.4.0
This is why xsbt-web-plugin becomes relevant even though you just want to change Scalatra's setting. The setting you need to rewire is called webappResources in Compile. How does that work?
rewiring webappResources
To rewire the setting, open project/build.scala. Add
import com.earldouglas.xsbtwebplugin.PluginKeys.webappResources
to the import clauses. Then change settings as follows:
lazy val project = Project (
"foo",
file("."),
settings = Defaults.defaultSettings ++ ScalatraPlugin.scalatraWithJRebel ++ scalateSettings ++ Seq(
organization := Organization,
name := Name,
version := Version,
scalaVersion := ScalaVersion,
resolvers += Classpaths.typesafeReleases,
webappResources in Compile := Seq(baseDirectory.value / "content" / "doc-root"),
...
)
)
Now move src/main/webapp to content/doc-root, reload sbt, and that should be it.
The resource folder is a Jetty property. If you're running embedded Jetty, it's specified here. You can edit it manually or override by setting the PUBLIC environment variable.
You also can override it in your SBT build file. It uses the xsbt-web-plugin to run, and you can override that plugin's settings.
For newer version of xsbt-web-plugin (1.0.0 as of writing) the way of changing source path is different.
First of all corresponding settings were moved to XwpPlugin.webappSettings. And you needs these two
webappSrc in webapp <<= (baseDirectory in Compile) map { _ / "content" / "doc-root" },
webappDest in webapp <<= (baseDirectory in Compile) map { _ / "content" / "doc-root" },
If you dont want to change the sbt settings, you can also do it programmatically by overriding serveStaticResource and using forward
override protected def serveStaticResource(): Option[Any] = {
// check to see if we need to alter the path to find the TRUE disk url
val incUrl = request.getRequestURI
if(incUrl.startsWith("/otherDir")) {
servletContext.resource(request) map { _ =>
servletContext.getNamedDispatcher("default").forward(request, response)
}
} else {
val trueUrl = "/otherdir" + incUrl
Option(servletContext.getRequestDispatcher(trueUrl).forward(request, response))
}
}
Disclaimer: You should also check that it doesn't go into an infinite loop.

How can one change the location of the "webapp" directory for a Scalatra application?

By default, Scalatra expects the "webapp" directory to be at src/main/webapp. How could that be changed to, e.g., content/doc-root?
sbt allows for customizing its default directories using something like the following:
scalaSource <<= (baseDirectory)(_ / "src")
So I assume it's just a matter of knowing the right "configuration key" to use...
#Kelsey Gilmore-Innis has the right answer, but since it's not accepted let's break it, break it, break it down.
First, I'm assuming you're following Getting started guide to install Scalatra using g8. Hopefully the same version I just got.
g8 scalatra/scalatra-sbt
What that g8 template did was to set up an sbt 0.13 build which uses scalatra-sbt 0.3.2 plugin:
addSbtPlugin("org.scalatra.sbt" % "scalatra-sbt" % "0.3.2")
This plugin internally uses JamesEarlDouglas/xsbt-web-plugin 0.4.0 to do the webapp-related settings.
xsbt-web-plugin 0.4.0
This is why xsbt-web-plugin becomes relevant even though you just want to change Scalatra's setting. The setting you need to rewire is called webappResources in Compile. How does that work?
rewiring webappResources
To rewire the setting, open project/build.scala. Add
import com.earldouglas.xsbtwebplugin.PluginKeys.webappResources
to the import clauses. Then change settings as follows:
lazy val project = Project (
"foo",
file("."),
settings = Defaults.defaultSettings ++ ScalatraPlugin.scalatraWithJRebel ++ scalateSettings ++ Seq(
organization := Organization,
name := Name,
version := Version,
scalaVersion := ScalaVersion,
resolvers += Classpaths.typesafeReleases,
webappResources in Compile := Seq(baseDirectory.value / "content" / "doc-root"),
...
)
)
Now move src/main/webapp to content/doc-root, reload sbt, and that should be it.
The resource folder is a Jetty property. If you're running embedded Jetty, it's specified here. You can edit it manually or override by setting the PUBLIC environment variable.
You also can override it in your SBT build file. It uses the xsbt-web-plugin to run, and you can override that plugin's settings.
For newer version of xsbt-web-plugin (1.0.0 as of writing) the way of changing source path is different.
First of all corresponding settings were moved to XwpPlugin.webappSettings. And you needs these two
webappSrc in webapp <<= (baseDirectory in Compile) map { _ / "content" / "doc-root" },
webappDest in webapp <<= (baseDirectory in Compile) map { _ / "content" / "doc-root" },
If you dont want to change the sbt settings, you can also do it programmatically by overriding serveStaticResource and using forward
override protected def serveStaticResource(): Option[Any] = {
// check to see if we need to alter the path to find the TRUE disk url
val incUrl = request.getRequestURI
if(incUrl.startsWith("/otherDir")) {
servletContext.resource(request) map { _ =>
servletContext.getNamedDispatcher("default").forward(request, response)
}
} else {
val trueUrl = "/otherdir" + incUrl
Option(servletContext.getRequestDispatcher(trueUrl).forward(request, response))
}
}
Disclaimer: You should also check that it doesn't go into an infinite loop.