These are chat archives for sbt/sbt-native-packager

24th
Feb 2016
Richard Gomes
@frgomes
Feb 24 2016 11:36
Does anyone have an idea why stage is not generating a bin folder in the configuration below? Thanks
    .enablePlugins(JavaAppPackaging)
    //more settings here
    .configs(Universal,MyConfig)
    .settings(inConfig(MyConfig)(
      Defaults.configSettings ++ JavaAppPackaging.projectSettings ++
      Seq(
        mainClass in ThisScope := Option(myMainClass))): _*)
I mean, I do this: MyModule/MyConfig:stage and I see the lib folder with all jars in it, but I don't see the bin folder. Ideas?
Richard Gomes
@frgomes
Feb 24 2016 11:43
I think that the problem is between the keyboard and the chair. A simple setting, without using configurations, straight on the module... is not generating the bin folder either. So, something very wrong is going on.
Richard Gomes
@frgomes
Feb 24 2016 11:59
Does it make any difference enablePlugins(JavaAppPackaging) on a global level of build.sbt or as a setting on a specific module? I don't see examples in the documentation covering the second option. I don't see examples in src/sbt-test covering the second option. Well... shouldn't... just to make sure someone ever tried that.
Gary Coady
@fiadliel
Feb 24 2016 12:01
enablePlugins is only defined in sbt.Project, so you’re actually enabling the plugin on the root project.
It’s completely supported and normal to have it on multiple projects.
Richard Gomes
@frgomes
Feb 24 2016 12:08
@fiadliel : Thanks
Richard Gomes
@frgomes
Feb 24 2016 12:19
Where I can find documentation for version 1.0.6, please?
Nepomuk Seiler
@muuki88
Feb 24 2016 12:22
Unfortunately we only have latest documentation.
Enabling the plugins on submodules is common and actually a feature, so you can customize things as needed.
What is the purpose for the custom config scope?
Richard Gomes
@frgomes
Feb 24 2016 12:34
@muuki88 : Our codebase is big and messy. I have one module which contains a number of applications in it, I mean: several mainClasses. Creating fat-jars for each application separately (in separate configs) using sbt-assembly is not an option at the moment, due to a messy jar hell with clashing libraries. So, the option is having multiple configurations which create multiple packages.
OK. The answer is that I have to have src/universal/bin/something in order to have something in a bin folder when I stage it. I cannot say it is clear to find it in the documentation.
Nepomuk Seiler
@muuki88
Feb 24 2016 15:51
Normally the issue with not having a bin folder is not having a mainClass defined. But you have.
However it doesn't seem to be picked up. I have the feeling UniversalPlugin only looks for the mainClass in Compile
Richard Gomes
@frgomes
Feb 24 2016 16:44
@muuki88 :: I guess that I assumed sbt-native-packager would create a launcher script for me. I've created now a /src/universal/bin/my-launcher-script which does the job... and it is working.
@muuki88 :: The main class makes sense in the case of a fat-jar, in the style sbt-assembly works. It also makes sense in case sbt-native-packager automagically creates a launcher for me. But, for whatever reason... apparently it doesn't.
Richard Gomes
@frgomes
Feb 24 2016 16:57
Am I missing something or there isn't a packageZip task? The documentation mentions packageBin for a .zip file, but MyModule/MyConfig:packageBin is only producing the .jar for the entire module. It's not producing the .zip as it would be expected. Maybe the very old difficulty (from SBT) involving configurations which do not really extend (read: inherit) settings from the "base" configuration?
Richard Gomes
@frgomes
Feb 24 2016 17:30
Changing settings mappings and topLevelDirectory does not produce any effect inside a configuration. Is this expected or am I missing something?
    .configs(Universal,BuilderRS)
    .settings(inConfig(BuilderRS)(
      Defaults.configSettings ++ JavaAppPackaging.projectSettings ++
        Seq(
          executableScriptName := "rs",
          mappings :=
            mappings.value
              .filter {
                case (file, name) =>  ! file.getAbsolutePath.endsWith("/bin/rv")
              },
          topLevelDirectory :=
            Some(
              "ftreports-" +
                new java.text.SimpleDateFormat("yyyyMMdd_HHmmss")
                  .format(new java.util.Date())),
          mainClass in ThisScope := Option(mainClassRS))): _*)
Richard Gomes
@frgomes
Feb 24 2016 17:36
Hum.... ok... If I specify scope Universal it works.
    .configs(Universal,BuilderRS,BuilderRV)
    .settings(inConfig(BuilderRS)(
      Defaults.configSettings ++ JavaAppPackaging.projectSettings ++
        Seq(
          executableScriptName := "rs",
          mappings in Universal :=
            (mappings in Universal).value
              .filter {
                case (file, name) =>  ! file.getAbsolutePath.endsWith("/bin/rv")
              },
          topLevelDirectory in Universal :=
            Some(
              "ftreports-" +
                new java.text.SimpleDateFormat("yyyyMMdd_HHmmss")
                  .format(new java.util.Date())),
          mainClass in ThisScope := Option(mainClassRS))): _*)
Richard Gomes
@frgomes
Feb 24 2016 17:55
@muuki88 :: maybe the trouble involving mainClass was due to scope ThisScope? I don't know if I will test it using scope Universal... not sure if I will have drive to break things after they converge to a solution.
Nepomuk Seiler
@muuki88
Feb 24 2016 18:45

That was my initial reason behind the "why are you using configuration scopes" as they cause more confusion then solving problems. It always hard to get this correct. And I personally avoid them whenever possible, because I still don't quite get it.

packageBin only produces a jar. universal:packageBin produces a zip. yourscope:packageBin produces whatever you have defined in that scope. Remember you have to inherit all the needed settings to makes things work. This includes the mappings. So you have to

mappings in YourScope := (mappings in Universal).value

To make thigns work

Richard Gomes
@frgomes
Feb 24 2016 19:16

@muuki88 :: This is what I was using:

          mappings in ThisScope :=
            (mappings in Universal).value
              .filter {
                case (file, name) =>  ! file.getAbsolutePath.endsWith("/bin/rv")
              },

So, I would expect that the plugin would pick mappings from the current scope, right? But unfortunately this is not what happens (at least in my use case).

  1. Then I've changed to mappings in Universal := ... instead. In this case it works.
  2. But I need several configurations. And obviously I've just copied/pasted the solution I've just found. But it does not work. And why not?
    --> Because the plugin always pick mappings in Universal and when I create another filter in another configuration and redefine mappings in Universal... I ended up chaining the two filters... which is not what I want.
So, IMHO, the plugin should pick mappings in ThisScope, instead of mappings in Universal. But I guess this would provoke a massive reengineering in the entire plugin. :-(
Richard Gomes
@frgomes
Feb 24 2016 19:26
I'm just arriving in this chat room and my knowledge of sbt-native-packager is virtually zero... but anyway... looks to me that JavaAppPackaging and other archetypes should actually be configurations extended from Universal. In this scenario, I would just create my own configuration extended from JavaAppPackaging and tweak the necessary bits according to my needs. And, finally, if the plugin just picks mappings in ThisScope... it would pick my own scope, and not JavaAppPackaging... and not Universal.
Richard Gomes
@frgomes
Feb 24 2016 19:59
I've opened: sbt/sbt-native-packager#746
Srepfler Srdan
@schrepfler
Feb 24 2016 22:35
can specify/overried a config file location when running sbt run?