These are chat archives for sbt/sbt

8th
Feb 2016
Sergio Hg
@sergiohgz
Feb 08 2016 08:01
Hi everyone
This message was deleted
Sergio Hg
@sergiohgz
Feb 08 2016 08:07

I use 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

Sam Halliday
@fommil
Feb 08 2016 08:25
Remove the -J and in Universal. I'm surprised your config compiles and apps run.
Sergio Hg
@sergiohgz
Feb 08 2016 08:34

@fommil modified code is

javaOptions ++= Seq("-Xmx512m", "-Xms512m")
fork in run := true

and continue with 1024m. I don't know why

Sam Halliday
@fommil
Feb 08 2016 08:43
Then you'll have to put together a small test project on github because it's a context issue.
Sergio Hg
@sergiohgz
Feb 08 2016 08:46
I'll try to make a simple project, let me a moment please
Sergio Hg
@sergiohgz
Feb 08 2016 10:35
@fommil Here is a repo with a simple project. It continues with 1024m, I don't understand why.
Could be 1024m for sbt and the app takes 512m?
Sam Halliday
@fommil
Feb 08 2016 10:52
@sergiohgz sorry if it's a build.sbt project I get lost. You'll need to wait for somebody else to have a look.
Sergio Hg
@sergiohgz
Feb 08 2016 10:53
Ok, thanks a lot
Sam Halliday
@fommil
Feb 08 2016 10:53
Probably something to do with initialisation order and your javaOptions := line
I only use .scala builds
Dale Wijnand
@dwijnand
Feb 08 2016 11:18
@sergiohgz yes it's probably sbt defaulting to 1024 and then the forked app taking 512
Sergio Hg
@sergiohgz
Feb 08 2016 11:33
I tries in this way and inside docker memory goes up to 1024, I try put that javaOptions in Docker
Dale Wijnand
@dwijnand
Feb 08 2016 11:45
you need to configure the sbt launcher, not sbt itself, run sbt -h it should help you find what you're looking for
andy scott
@andyscott
Feb 08 2016 17:59
I have an expensive task I want to use for generating source and resources files. How can I cache/reuse the output of this task between my sourceGenerator and resourceGenerator?
Fundamentally, in my situation it would make more sense to generate the source and resource files at the same time.
Tim Harper
@timcharper
Feb 08 2016 20:56

@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 <me@email.com>"

...

instead of this:

Revolver.settings

PB.protobufSettings

enablePlugins(JavaServerAppPackaging)

maintainer := "me <me@email.com>"

...
Having a single import reduces the probability of namespace collision, at the cost of a little extra verbosity. In this case, I think the tradeoff is warranted. It makes SBT a little less magical, and I think that's the direction sbt should probably go if it wishes to stem the tide of SBT magic hate.
Sam Halliday
@fommil
Feb 08 2016 20:58
did you mean to have native.enablePlugins?
Tim Harper
@timcharper
Feb 08 2016 20:59
sorry, no
lol that supports my point
you can't tell if enablePlugins comes from sbt or from a plugin.
it's all mixed in. It's hard to follow.
Sam Halliday
@fommil
Feb 08 2016 21:00
yeah, that's cool
but might be a big burden for everybody to upgrade?
maybe a 2.0 change?
Tim Harper
@timcharper
Feb 08 2016 21:01
if it doesn't happen in 1.0.0 then when ?
ugh... too long away
sbt plugins will need to recompile for the 1.0.0 transition anyways. I suppose with 1.0.0 it could be a deprecation warning, then enforced in 2.0.0
but since binary compatible breaks with 1.0.0 why not just do it?
I'll open up an issue on sbt and we can have a thread of discussion there
Dale Wijnand
@dwijnand
Feb 08 2016 21:06
:+1: for opening an issue
Sam Halliday
@fommil
Feb 08 2016 21:06
but not source compatibility I thought?
Tim Harper
@timcharper
Feb 08 2016 21:06
@fommil please clarify
Sam Halliday
@fommil
Feb 08 2016 21:06
I may not know the details, but I thought 0.13 plugins were supposed to have a relatively painless upgrade path to 1.0.
Dale Wijnand
@dwijnand
Feb 08 2016 21:08
Yeah that sounds right, it would be generally straight forward, following deprecation warnings and/or a migration guide/outline ("all foo things are now no longer under sbt, but under sbt.foo")
Perry
@pfn
Feb 08 2016 21:08
yeahright :P
I'm told my plugins are pretty much gonna be dead meat for 1.0
Dale Wijnand
@dwijnand
Feb 08 2016 21:09
but radical changes like what you describe should be (should've been) experimented in the 0.13.5+ preview releases
@pfn dead meat why?
Perry
@pfn
Feb 08 2016 21:09
because my biggest plugin works intensively with sbt internals
Dale Wijnand
@dwijnand
Feb 08 2016 21:10
hmm
Perry
@pfn
Feb 08 2016 21:10
well, not that extensively, but it does work on top of session settings and such
Sam Halliday
@fommil
Feb 08 2016 21:10
@pfn well I heard there was a special effort to block your plugins :-P
as I've heard, there's really no analog that'll just work for that
and some other things as well
Sam Halliday
@fommil
Feb 08 2016 21:11
sbt-big-project will probably break too
Tim Harper
@timcharper
Feb 08 2016 21:15
sbt/sbt#2447
Man, the more I think of this... this would significantly improve my experience with sbt. It's a no brainer. This should have been done a long time ago. If we miss the opportunity to fix this with 1.0.0, then it seems like it will be an opportunity lost.
Tim Harper
@timcharper
Feb 08 2016 22:00
@dwijnand to which sonatype sbt plugin are you referring? sbt-sonatype defines no such maintainer key.
Dale Wijnand
@dwijnand
Feb 08 2016 22:04
hypothetical
Tim Harper
@timcharper
Feb 08 2016 22:07
oh, okay
I responded to your comment with a concrete way to reproduce the error
perhaps I answered a different question
Tim Harper
@timcharper
Feb 08 2016 22:43
This message was deleted
This message was deleted
This message was deleted
Dale Wijnand
@dwijnand
Feb 08 2016 22:46
This message was deleted
Tim Harper
@timcharper
Feb 08 2016 22:46
sorry I realized it after the fact
lol shouldn't have deleted my messages. Bad form.
Dale Wijnand
@dwijnand
Feb 08 2016 22:47
YEAH WELL THE NSA WON'T FIND OUT NOW
:P
eugene yokota
@eed3si9n
Feb 08 2016 22:48
added my response
Tim Harper
@timcharper
Feb 08 2016 22:48
sssssh don't tell them where to look!
eugene yokota
@eed3si9n
Feb 08 2016 22:49
namespacing the Scala instance doesn't mean much to sbt's key-value space
Tim Harper
@timcharper
Feb 08 2016 22:54
lol, looks like I basically had the exact same idea as the individual who identifies themself as "Fluffy"
well... some major sbt projects aren't following the convention :(
like sbt-native-packager
which is super sad
I'll respond to that issue in a bit
eugene yokota
@eed3si9n
Feb 08 2016 22:57
Fluffy = the original author of the sbt-native-packager plugin = @jsuereth
Tim Harper
@timcharper
Feb 08 2016 23:42
hahaha! That's hilarious, I was about to comment how sbt-native-packager seems to be following that convention in the build.sbt file.