These are chat archives for sbt/sbt
A relaxed chat room about sbt (That interactive build tool). For getting help on sbt, we encourage people to document it on Stackoverflow or subscribing to Lightbend subscription.
sbt run command and want to run with 512m Xmx and Xms parameters, but proccess don't take care about them. Everytime put them to 1024m. These params are definened in build.sbt:
javaOptions in Universal ++= Seq( "-J-Xmx512m", "-J-Xms512m" ) fork in run := true
How can I make them work? Thank you so much
in Universal. I'm surprised your config compiles and apps run.
@fommil modified code is
javaOptions ++= Seq("-Xmx512m", "-Xms512m") fork in run := true
and continue with 1024m. I don't know why
sbt -hit should help you find what you're looking for
@eed3si9n I've been thinking over the weekend that for sbt 1.0.0 it might be a good idea to restrict the number of autoImports from a plugin to one, and encourage sbt plugin authors to create a single package object which containers their stuff.
I generally tend to avoid
import package._ because it hurts legibility. Having every provided sbt key mixed into a single keyspace dramatically increases the complexity.
I'd much prefer something like this:
revolver.settings scalapb.settings enablePlugins(native.JavaServerAppPackaging) native.maintainer := "me <firstname.lastname@example.org>" ...
instead of this:
Revolver.settings PB.protobufSettings enablePlugins(JavaServerAppPackaging) maintainer := "me <email@example.com>" ...
enablePluginscomes from sbt or from a plugin.
1.0.0transition anyways. I suppose with
1.0.0it could be a deprecation warning, then enforced in
1.0.0why not just do it?
sbtand we can have a thread of discussion there
1.0.0, then it seems like it will be an opportunity lost.
sbt-native-packagerseems to be following that convention in the