Systemloader AutoPlugins

Breaking Changes

This release transfer the systemloader feature from the JavaAppServerPackaging archetype to a new set of archetype plugins called systemloader plugins.

Migration

Assuming you have build like this

enablePlugins(JavaServerAppPackaging)

you must now add a systemloader explicitly via an AutoPlugin.

enablePlugins(JavaServerAppPackaging, SystemdPlugin)

You also need to remove code like this as it will not work anymore

// import is wrong
import com.typesafe.sbt.packager.archetypes.ServerLoader
// will have strange effects
serverLoading in Rpm := ServerLoader.Upstart
serverLoading in Debian := ServerLoader.SystemV

Motivation

Why did we change this behaviour?

1. Default choices for systemloaders are to fragile as these vary from distribution and version
2. Customization was not really possible. Now we can provide systemloader specific task/settings to customize the systemloader configurations
3. Reusability. You are now free to use systemloaders with everyother archetype without the setup the JavaServerAppPackaging adds. For example enablePlugins(JavaAppPackaging, SystemdPlugin) is enough if you don't need log and pid folders or the etc-default support.
4. Cleaner code. This is affects you directly as we can change systemloader behaviour faster and fix bugs in the plugin responsible for the specific systemloader. Next steps will be to add customization for systemd ( see #785 for a list of related issues ).

This changes however come at a price. You now only can use one systemloader per sbt-module. If you need different systemloaders for rpm/debian, you will have to create two submodules with different configurations.

See #785 for the initial discussion.

Commits and the issues they fixed since v1.1.1

Issue(s)	Commit	Message
#785	0a6be58	Extract Systemloaders into AutoPlugins (#785) * Add systemd plugin. Idea on how

Pull requests since v1.1.1

Pull Request(s)	Commit	Message

A big thank you to all the contributors!

#	Author
3	Nepomuk Seiler