Add "javaOptions in Docker" possibility for build.sbt

[netknight]

I've using native-packager for docker image creation. So the problem is next: Currently I could specify:

javaOptions in Universal := ...

But this this will be applied for all packaging types (Docker, RPM, DEB, etc).

I would like to specify docker-only javaOptions but this is impossible now because javaOptions in Docker := ... is ignored (checked with sbt inspect).

[muuki88]

That's correct. The feature is implemented in the JavaApp Archetype.

You would need to generalize this method with some like this

def appendJvmOptions(config: Configuration): Setting[_] = {
   mappings in config := { 
      val originalMappings = (mappings in config).value
      bashScriptConfigLocation.value.collect {
        // generate the application.ini when constraints are okay
     }.getOrElse(originalMappings)
   }
}

Not sure if the sbt syntax works, but this is how it could look like. Then you could do something like this in the java app archetype:

appendJvmOptions(Universal),
appendJvmOptions(Docker),
appendJvmOptions(Rpm),
appendJvmOptions(Debian)

[netknight]

May be better option is to extend this functionality in JavaServerApp?

[muuki88]

Not necessarily. It's just that the creation of the application.ini from the javaOptions must be more generic. The JavaServerApp archetype adds the etc-default customization option.

[muuki88]

Update: This feature has moved to the BashStartScriptPlugin

[mkurz]

This is a highly needed feature. Because: To make Play Framework applications work nicely with Docker, you usually have to set

javaOptions in Universal ++= Seq(
  "-Dpidfile.path=/dev/null"
)

As it seems many people are effected by this. Now, if I want to use sbt-native-packager to also publish deb packages, that sucks, because I obviously don't want to apply that above pid workaround for my debian package.

Another thing: Does even javaOptions in Linuxwork? Look at the source, here you pass javaOptions in Universal to generateApplicationIni: https://github.com/sbt/sbt-native-packager/blob/4b7d91739c5409f3b9578232aeb30a320cf8f42c/src/main/scala/com/typesafe/sbt/packager/archetypes/scripts/BashStartScriptPlugin.scala#L69-L75 No mention of javaOptions in Linux... I am not an sbt expert, but how does that work if I set javaOptions in Linux? Will such linux javaOptions merged into the universal javaOptions? (Again I am not an sbt expert).

I see you added a test for javaOptions in Linux, however this just reads the value https://github.com/sbt/sbt-native-packager/blob/4b7d91739c5409f3b9578232aeb30a320cf8f42c/src/sbt-test/universal/application-ini-from-javaoptions/build.sbt#L12-L15 to compare it with what was set by javaOptions in Universal a couple of lines above: https://github.com/sbt/sbt-native-packager/blob/4b7d91739c5409f3b9578232aeb30a320cf8f42c/src/sbt-test/universal/application-ini-from-javaoptions/build.sbt#L7 Note - also here I can just see how the Linux settings gets set to the Universal ones by default, but I can not find out how this Linux javaOptions will be used later: https://github.com/sbt/sbt-native-packager/blob/4b7d91739c5409f3b9578232aeb30a320cf8f42c/src/main/scala/com/typesafe/sbt/packager/archetypes/JavaServerApplication.scala#L50-L51

[mkurz]

Correcting my own comment after I finally skimmed through the whole documentation:

Now, if I want to use sbt-native-packager to also publish deb packages, that sucks, because I obviously don't want to apply that above pid workaround for my debian package.

The docs actually describe exactly this cited use case: "Build the same package with different configs". I guess the sub modules approach is the way to go and makes this feature request less urgent.

[muuki88]

Thanks @mkurz for all the research :hugs: This is some pretty old code and not necessarily the state-of-the-art sbt craftmanship :wink:

Now, if I want to use sbt-native-packager to also publish deb packages, that sucks, because I obviously don't want to apply that above pid workaround for my debian package.

I actually would recommend that :smile: My personal experience is that using the SystemLoaders (systemd, systemv, upstart) is a better option then letting play handle its lifecycle.

No mention of javaOptions in Linux... I am not an sbt expert, but how does that work if I set javaOptions in Linux? Will such linux javaOptions merged into the universal javaOptions`?

There's no merging going on AFAIK. Actually I have no clue how this works. Couldn't find any trace of javaOptions. So... don't know.