These are chat archives for sbt/sbt

12th
Feb 2015
Dave Gurnell
@davegurnell
Feb 12 2015 11:01
Hi all. Does anyone know how to get a Swing app to quit cleanly when you press Ctrl+D in an SBT Scala console?
Erik Allik
@eallik
Feb 12 2015 11:10
@davegurnell first thing that comes to mind is sys.addShutdownHook
I think you can delay the shutdown of a JVM in there, IIRC
Dave Gurnell
@davegurnell
Feb 12 2015 11:28
@eallik Cheers! I'll take a look. I have a partially working solution using SBT's cleanupCommands key to manually call a shutdown method.
Erik Allik
@eallik
Feb 12 2015 11:40
@davegurnell I'd assume you'd want a clean shutdown outside of SBT as well...?
Dave Gurnell
@davegurnell
Feb 12 2015 11:44
I'm not super bothered about that. This is for a set of tutorials. I want people to be able to write code, run it in the console, edit the code, rerun the console, etc... without quitting to the OS every time.
But the code I'm writing will be "on display" to the tutees, so it ought to be written "the right way".
...or I could prepend it with // FIXME :)
Josh Suereth
@jsuereth
Feb 12 2015 13:25
sbt never shuts down the JVM
BUT if you do exitOnClose on the JFrame it should work ok
OH, you mean when you press Ctrl+D
RIght....
THe answer is nuanced and scary
eugene yokota
@eed3si9n
Feb 12 2015 13:26
I would like to remind Q&A stuff should go to stackoverflow tho
Josh Suereth
@jsuereth
Feb 12 2015 13:27
WE have a "taskCancellationPolicy" key (name might be off). THis is what captures signals, like Ctrl+D
eugene yokota
@eed3si9n
Feb 12 2015 13:27
useful info should be reused
"This room is for sbt-plugin + sbt development related discussions"
Josh Suereth
@jsuereth
Feb 12 2015 13:27
YOu'll have to replace that with your own that knowns how to shutdown swing
IF you figure that out, please post it somewhere
Also there is a flat "sbt" channel for regular #irc chit-chat
eugene yokota
@eed3si9n
Feb 12 2015 13:33
just RT'ed sbt support on jitpack - https://jitpack.io/
With JitPack all the author needs to do is create a GitHub Release and the project becomes available for everyone to use. So sharing releases is simpler for authors as well.
Dave Gurnell
@davegurnell
Feb 12 2015 13:54
@eed3si9n Understood -- will SO in future. @jsuereth @eallik Thanks!
Indrajit Raychaudhuri
@indrajitr
Feb 12 2015 17:52
@eed3si9n / @jsuereth, See if you guys have any thought on #1831. No push though, but I'd like to wrap this up sooner before getting distracted by something else. (I am open to continue the discussion in sbt-dev as well, if it suits better).
eugene yokota
@eed3si9n
Feb 12 2015 17:54
hey @indrajitr
given that there's been poms published with info.apiURL, I don't know if deprecating that is worth it
Indrajit Raychaudhuri
@indrajitr
Feb 12 2015 17:56
info.apiURL on existing poms would be honored. Just that new poms would have info.scalaApiURL
eugene yokota
@eed3si9n
Feb 12 2015 17:56
can we assume the existing stuff is Scala only?
Indrajit Raychaudhuri
@indrajitr
Feb 12 2015 17:57
Meaning?
eugene yokota
@eed3si9n
Feb 12 2015 17:57
and just add info.javaApiURL?
realistically whichever project that used apiURL is essentially the same as info.scalaApiURL, isn't it?
Indrajit Raychaudhuri
@indrajitr
Feb 12 2015 17:57
Oh, ok you mean not rename info.apiURL to info.scalaApiURL and just add info.javaApiURL?
eugene yokota
@eed3si9n
Feb 12 2015 17:58
yea. I am thinking that's more conservative
Indrajit Raychaudhuri
@indrajitr
Feb 12 2015 17:58
True, but probably won't survive over time.
3 years down the line -- the property name with fail 'self documented' test ;)
eugene yokota
@eed3si9n
Feb 12 2015 18:01
maybe. but i don't want to break poms without really good reasons esp if we have to support the reading forever
Indrajit Raychaudhuri
@indrajitr
Feb 12 2015 18:01
Where all are you seeing the possibility of beaking poms?
eugene yokota
@eed3si9n
Feb 12 2015 18:02
not exactly breaking, but now we'll get different poms depending on different version of sbt right?
Indrajit Raychaudhuri
@indrajitr
Feb 12 2015 18:03
Ok, I see what you mean. Yes, that would be case.
eugene yokota
@eed3si9n
Feb 12 2015 18:04
is there technical merit for the rename besides consistency?
Indrajit Raychaudhuri
@indrajitr
Feb 12 2015 18:06
So there could potentially be case where you publish an upstream lib with sbt 0.13.8 (and thus have scalaApiURL), however downstream library might have been using sbt 0.13.6 which won't see apiURL.
No the merit isn't technical -- we can live with that. I am worried about continuing to add to the non-intuitiveness of sbt.
info.apiURL doesn't convey that it is for scaladoc only. And there is no way to guess that correctly either (unless one reads the doc/code). And there is neither a way to guess that info.javaApiURL is the javadoc peer.
eugene yokota
@eed3si9n
Feb 12 2015 18:11
ok. I'll write a comment on the PR and ask what @jsuereth thinks
Indrajit Raychaudhuri
@indrajitr
Feb 12 2015 18:11
The other option is keep both info.apiURL and info.scalaApiURL around in the POM (for a finite compatibility window). But that's quite in-elegant as well.
eugene yokota
@eed3si9n
Feb 12 2015 18:11
I'm more ok for aiming for better consistency on Keys.scala
Indrajit Raychaudhuri
@indrajitr
Feb 12 2015 18:12
Yes, agreed. And for all practical purpose variables embedded in pom are really for non-sbt POM parsers. So this is probably more of a dev facing variable than a user facing variable.
eugene yokota
@eed3si9n
Feb 12 2015 18:16
ok. comment is written. if you can convince Josh, I'll yield. gotta get back to coding. ttyl
Indrajit Raychaudhuri
@indrajitr
Feb 12 2015 18:17
Cheers. And thanks for the input!