I want to attach sbt-native-packager to a root-aggregate of a project, but that root project has published name for Maven of "foobar". I want the artifact generated through universal:packageBin to consistently use "foo" instead.
How do I accomplish this?
I tried
name in Universal := "foo"
executableScriptName in Universal := "foo"
etc. None has an effect. I end up having bin/foobar and bin/foobar.bat.
executableScriptName is not properly scoped, so you have to do the following"
executableScriptName := "foo"
Related
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/"
Is there an SBT task to increment a project's version?
Given an initial configuration of something like the following build.sbt
name := 'My Project'
organization := 'org.example'
version := '0.1.0'
and a versioning nomenclature of major.minor.patch, I was hoping for an SBT task like
> incrementVersionPatch
that would result in a version of 0.1.1.
(Ideally also the corresponding incrementVersionMinor and incrementVersionMajor.)
I feel like this must already exist but cannot find a way to do it.
I think what you need is sbt-release plugin that "provides a customizable release process that you can add to your project." with "the setting release-version-file, which is set to file("version.sbt") by default and points to $PROJECT_ROOT/version.sbt".
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!
Is it possible to change play dist output file name apart from modifying appName on Build.scala?
I'm trying to automate the creation of two different zip files from the same project tree, e.g.: myapp-production-1.0-SNAPSHOT.zip and myapp-integration-1.0-SNAPSHOT.zip.
Thank you very much!
For Play Framework 2.4 changing the name of the output file worked like this in build.sbt:
packageName in Universal := "dist"
In Play Framework 2.2, you can add the following line to the build.sbt file:
name in Universal := "dist"
Your app will be packaged in target/universal/dist.zip
You can modify the output by changing the build.sbt file in your project directory.
name := "myname"
version := "1.0-SNAPSHOT"
Remember to recompile, might have to clean too.
I was wondering if there is a difference in SBT between a project's name and id.
I noticed example build.sbt files with the following key:
name := "My Project"
And I noticed Build.scala files with:
Project(id = "My Project", base = file("."))
Is there a difference? Should the two be the same or is it irrelevant? What are they used for?
Thanks!
Project name should be used for the name of your project, the visible title for any documentation.
Id is used to refer to the project to modify settings or in terms of dependancy management, i.e to connect a subproject to a root project you can say subproject.dependsOn(rootProjectId)
In your build.sbt file you have a single project definition. You can also pass a name attribute to the settings of a Project in your build.scala. As you can have several sub projects in a build file, you have to provide an id for each of them, while the project name remains the same.