These are chat archives for sbt/sbt-native-packager
IMHO this is out of scope for sbt-native-packager. Generalizing over how you configure you different environments depends heavily on your use case.
You can go from config files, env-variables over cmd-line parameters to automation tools like puppet/chef.
SBT's support for multiple modules lets you solve the "different package types" very elegantly and without any sbt-related confusions (really, Scopes/Configs
are counter-intuitive even if you have used them a couple of times ). And they don't require much configuration.
submodule-per-packageapproach is feasible when really heavy customizations are needed. But necessity to support multiple service-loaders is just what we have today: lots of organizations run Ubuntu servers for example and Ubuntu is in transition between init systems.
I understand your pain and we try really hard to make the usage-experience as smooth as possible.
My concern is, that generalizing this configuration stuff will make the code base a lot more complex and harder to maintain.
SBT is a sophisticated build tool. Adding complexity makes it even more harder to reason what's going on. IMHO subprojects
are a simple, easy to grasp concept ( most build tools have it, and things-depending-on-things is a devs daily business ) and they are
easy to configure with
lazy val app = project("app") .settings() lazy val ubuntuTrusty = project(file(".ubuntu-trusty") .enablePlugins(JavaServerAppPackaging) .settings( systemLoader in Debian := Upstart ) .dependOn(app) lazy val ubuntuVivid = project(file(".ubuntu-trusty") .enablePlugins(JavaServerAppPackaging) .settings( systemLoader in Debian := SystemD ) .dependOn(app)
Now you can call
and you will get you packages configured as needed. On your way you can add more
and more customization if needed.
In short, adding things to generalize over configs is hard to do (I actually have no
initial idea on how to do this), harder to debug for a, IMHO, little gain.
What would you expect the API to look like, if we would decide to implement this?
Commands) and now I've made single package but with 2 service loaders bundled inside. Now I feel that my initial intent was not what I needed. This is what I have now:
lazy val packagingSettings: Seq[Setting[_]] = Seq( // //... other required debian settings // linuxMakeStartScript in Debian := None, linuxPackageMappings <++= (packageName, sourceDirectory, target in Universal, linuxScriptReplacements in Debian) map startScriptMapping(Upstart), linuxPackageMappings <++= (packageName, sourceDirectory, target in Universal, linuxScriptReplacements in Debian) map startScriptMapping(Systemd) )
startScriptMappingis a helper function I had to pull up from
Seq- then it becomes tricky to generate pre/post actions in maintainerScripts
Hm. I like your approach. This way you would only have to build one jar. And you could choose your systemloader based on any task you want.
startScriptMapping available from the outside would make this a lot easier, right?
If you make a pull request, adding the method to a new
autoImport object in https://github.com/sbt/sbt-native-packager/blob/master/src/main/scala/com/typesafe/sbt/packager/archetypes/JavaServerApplication.scala and add the necessary documentation, we could surely add this.
DebianDeployPlugin. As I see - it's only capable of publishing *.deb package to servers like nexus and artiifactory with maven/ivy layout repos, right?