If you want to build your application with different settings, e.g. for test, staging and production, then you have three ways to do this.
Tip
All examples are shown in a simple build.sbt
. We recommend using AutoPlugins to encapsulate certain aspects of your build.
All examples can also be found in the native-packager examples,
The main idea is to create a submodule per configuration. We start with a simple project build.sbt
.
In the end we want to create three different packages (test, stage, prod) with the respective configurations. We do this by creating an application module and three packaging submodules.
Now that our application is defined in a module, we can add the three packaging submodules. We will override the resourceDirectory
setting with our app
resource directory to gain easy access to the applications resources.
Now that you have your build.sbt
set up, you can try building packages.
This technique is a bit verbose, but communicates very clear what is being built and why.
SBT is a java process, which means you can start it with system properties and use these in your build. This pattern may be useful in other scopes as well. First we define an AutoPlugin that sets a build environment.
This plugin allows you to start sbt for example like
Now we can use this buildEnv
setting to change things. For example the mappings
. We recommend doing this in a plugin as it involes quite some logic. In this case we decide which configuration file to map as application.conf
.
Ofcourse you can change all other settings, package names, etc. as well. Building different output packages would look like this
The other option is to generate additional scopes in order to build a package like prod:packageBin
. Scopes behave counter intuitive sometimes, why we don't recommend this technique.
Error
This example is work in progress and doesn't work. Unless you are not very familiar with sbt we highly recommend using another technique.
A simple start may look like this
You would expect prod:packageBin
to work, but extending scopes doesn't imply inheriting tasks and settings. This needs to be done manually. Append this to the app
project.
Note that you have to know more on native-packager internals than you should, because you override all the necessary settings with the intended values. Still this doesn't work as the universal plugin picks up the wrong mappings to build the package.