SBT Native Packager 1.2.0

Native Packager 1.2.0 will come with a bunch of new features and some necessary changes. Some of this features are already implement in the current milestone (1.2.0-M5). Feel free to try them and provide feedback in our gitter channel or open an issue if you find a bug.

The features are in no particular order.

Systemloaders are AutoPlugins now

Previously, the Java Server Application Archetype provided a setting serverLoading where you could define your system loader like this:

import com.typesafe.sbt.packager.archetypes.ServerLoader

serverLoading in Rpm := ServerLoader.Upstart

This adds the necessary configuration files and maintainer scripts (postinst, postun, etc. ) in order to register and start your application.

The biggest problem with the tight coupling between the server archetype and the systemloaders is that it’s hard to add systemloader specific settings without changing a lot in the server archetype. It’s also a lot harder to reason about the code and the output. With extra systemloader plugins we open the possibility to

• easily extend a single systemloader
• have a place to put generic systemloader functionality ( there is a SystemLoaderPlugin which takes care of common settings )
• test systemloaders in isolation
• better developer experience

You enable a systemloader by enabling a concrete systemloader plugin

enablePlugins(SystemdPlugin)

For the complete discussion you can take a look at the pull request.

Single Project — Multiple Apps

A major pain point for beginners is the start script creation. The bash and bat start scripts are only generated when there is a either

1. Exactly one main class
2. Explicitly set main class with
   mainClass in Compile := Some(“com.example.MainClass”)

For 1.2.x we will extends the implementation and support multiple main classes by default.

Native packager will generate a start script for each main class found on the classpath. SBT provides them via the discoveredMainClasses in Compile task. If there is only one main class, SBT will assign it to the mainClass in Compile setting. This leads to three cases

1. Exactly one main class. In this case native-packager will behave like previous versions and just generate a single start script, using the executableScriptName setting for the script name.
2. Multiple main classes and mainClass in Compile := None . This is the default behaviour defined by SBT. In this case native-packager will generate the same start script for each main class.
3. Multiple main classes and mainClass in Compile := Some(…). The user has set a specific main class, which will lead to a main start script being generated using the executableScriptName setting. For all other main classes native-packager generates forwarder scripts.

Stage task

SBT comes with a stage task. Its purpose is to the prepare everything to build a package. As an example docker:stage creates a directory with a Dockerfile and all files included in the docker image. Now you could execute the docker build tool yourself.

Currently some package formats have their own tasks to perform extactly this task, e.g. debianExplodedPackage. With 1.2.x native-packager will provide a consistent behaviour through out all package formats.

Maintainerscripts

In 1.1.0 we added a maintainerScripts setting to provide a single data structure for lifecycle / maintainer scripts supported by a package format. This includes rpm scriptlets or debian postun, etc.

The 1.2.0 release series will be the last series supporting the old custom settings. Check out the migration guide in the release description.

Schedule?

I would love to announce a day, week or month when we will have finished implementing all this. Unfortunately I can’t. Native-packager is developed in the free time of the core maintainers and by more than 120 other contributors (work or free time). This makes planning almost impossible. So if you want to make this happen faster come and join the native-packager contributors :)