When using sbt console I find myself repeatedly entering some import statements. It would be great if there was a way to tell sbt to always run commands. Is there a way?
At the moment I have a kinda crufty solution:
( echo "import my.app._
import my.app.is.sooo.cool._" && cat ) | sbt console
Googleability words:
Initial commands, first commands, initial expressions, build file, initial statements, startup expressions, startup commands, startup statements.
You can use initialCommands:
initialCommands in console := """import my.app._
import my.app.is.sooo.cool._"""
Given that "sbt console" lets you run the scala repl, why not just create a custom .scala file (say "default.scala") where to store all the imports, and then just run :load /path/to/default.scala? This would achieve what you need in a persistent way.
Related
I'm moving my first steps with Scala (2.12.7) and SBT (1.2.7).
At some point, I want to get secret value from the environment:
sys.env("SECRET_TOKEN")
The problem is that, in the sbt shell, SECRET_TOKEN is not defined, therefore the application crashes.
So:
$ export SECRET_TOKEN="xxx"
$ sbt
[... sbt loads]
sbt> run
[ crashes because of the env var not found ]
It's like the sbt shell would get only a subset of the current environment.
Am I missing something?
Thanks
sbt (script + launcher) just launches a fancy java process, which should inherit the environment variables from the parent process.
Given
$ export SECRET_TOKEN="xxx"
Both build.sbt and your application during run should have access to sys.env("SECRET_TOKEN").
In the comment section, Bruno suggested SECRET_TOKEN="xxx" sbt, which apparently worked, but I don't know how that's different from export.
In any case,
object Hello extends App {
println(sys.env("SECRET_TOKEN"))
}
works for me
sbt:hello> run
[info] Running Hello
xxx
When I start the Scala REPL, is there a way to put Scala code or source files on the command line to automatically run? I would like to have some imports done automatically (on the command line in a bash script) at startup for user convenience.
Instead of Scala REPL use Ammonite. It is much better than the Scala REPL.
The best part about ammonite is that you can create a file called predef.sc under ~/.ammonite folder. Here you can specify SBT dependencies like interp.load.ivy("joda-time" % "joda-time" % jodaVersion) and also imports like import scala.concurrent.ExecutionContext.Implicits.global
Now each time you start the ammonite REPL you have all SBT dependencies and imports already present. How cool is that.
If your project has a build.sbt file then you can add something like this to that file:
initialCommands in console :=
"""
import java.net._
import java.time._
import java.time.format._
import java.time.temporal._
import javax.mail._
import javax.mail.internet._
"""
Not sure how clear that is but it is simply a block string using triple quotes
Saves a lot of time having that collection of basic classes (whatever classes make sense for your work) handy!
When using the cobertura-maven-plugin for Java, I get a nice <instrumentation> block in the config where I can put the incredibly useful <ignoreMethodAnnotation> block.
Best thing to happen to coverage since the gin martini.
Now I'm using scoverage-sbt, but I can't seem to find where I can configure it! The available keys in build.scala are limited. I can do package exclusion and file exclusion but there's nowhere to tell cobertura anything else.
Is there a -D I can supply on the SBT command line, maybe?
There is no similar configuration in Scoverage ATM.
update:
You can use special comments to exclude a block of code from instrumentation:
// $COVERAGE-OFF
...
// $COVERAGE-ON$
One way to pass parameters and commands into SBT from the command line is:
$ sbt 'set coverageEnabled := true' clean coverage test coverageReport coverageAggregate codacyCoverage
Where you call SBT once and then separate each parameter or command by a space.
In this example, I first set the property coverageEnabled := true and then run several commands in sequence: clean, coverage, test, coveraReport, coverageAggregate and finally codacyCoverage
Please note that setting properties like this requires that you enclose your statements in single quotes, for example:
$ sbt 'set coverageEnabled := true'...
If I run the below script (saved as jarAccessTest.sh, which is an executable file) in a command line, nothing happens:
#!/bin/sh
# exec scala -classpath "/usr/local/google/home/vvasuki/sanskritnlpjava/target/sanskritnlp-1.0-SNAPSHOT.jar " "$0" "$#"
exec scala "$0" "$#"
!#
# import sanskritnlp.transliteration._;
print "hello"
I just see no output. Nothing. Command prompt does not return either.
What is happening here? I have to type Ctrl+C to stop whatever is happening.
EDIT: Using scala 2.9 in ubuntu 14.04 : http://i.imgur.com/VMYKnUX.png
Your pre-packaged version of Scala is from a long time ago and a galaxy far, far away.
You'll do better to download the latest 2.11.6 from the website.
When the scala runner runs a script, it starts a compile server process. If that process is borked, you may have to kill it or run fsc -shutdown to ask it nicely to go away.
You can try adding the -nc option to your script to eliminate that factor, i.e., scala -nc says no compile daemon.
Finally, if you're just testing your library, it's more common to run scala -cp my.jar and experiment from the REPL. Or if you are using SBT, start the console from there.
Anonymous suggests adding: "They seriously let you type anything on here"
To which I'll append the advice from the other answer, to run fsc -verbose. And note that they threaten to stop supporting fsc because it has issues which are maddening when they occur. For that reason, I prefer scala -nc for brief testing and scalac -d script.jar script.scala where script is an App.
The problem on the original computer was never really explained, though it is pointed out that use of the '-nc' flag worked.
The original problem might with the compilation daemon's ability to open a port. From the man page for fsc:
The first time it is executed, the daemon is started automatically.
On subsequent runs, the same daemon can be reused, thus resulting in a faster compilation. The tool is especially effective when repeatedly
compiling with the same class paths, because the
compilation daemon can reuse a compiler instance.
One way to check if this is the problem is to run fsc on its own with the verbose flag. For example, make a script called hello.scala with
println("Hello")
in it, and run
fsc -verbose hello.scala
If this shows the compile server unable to connect, you've identified your problem. A first thing to try in that case would be to check that your hosts file is kosher.
(I had a similar problem, and this is what I found).
you have a few changes to do on your code, mainly on the # line which is not a comment in scala.
#!/bin/sh
# exec scala -classpath "/usr/local/google/home/vvasuki/sanskritnlpjava/target/sanskritnlp-1.0- SNAPSHOT.jar " "$0" "$#"
exec scala "$0" "$#"
!#
// import sanskritnlp.transliteration._;
print ("hello\n")
I'm trying to get sbt to compile and build some benchmarks. I've told it to add the benchmarks to the test path so they're recompiled along with tests, but I can't figure out how to write an action to let me actually run them. Is it possible to invoke classes from the Project definition class, or even just from the command line?
Yes, it is.
If you'd like to run them in the same VM the SBT is run in, then write a custom task similar to the following in your project definition file:
lazy val benchmark = task {
// code to run benchmarks
None // Some("will return an error message")
}
Typing benchmark in SBT console will run the task above. To actually run the benchmarks, or, for that matter, any other class you've compiled, you can reuse some of the existing infrastructure of SBT, namely the method runTask which will create a task that runs something for you. It has the following signature:
def runTask(mainClass: => Option[String], classpath: PathFinder, options: String*): Task
Simply add the following to your file:
lazy val benchmark = task { args =>
runTask(Some("whatever.your.mainclass.is"), testClasspath, args)
}
When running benchmarks, it is sometimes recommended that you run them in a separate jvm invocation, to get more reliable results. SBT allows you to run separate processes by invoking a method ! on a string command. Say you have a command java -jar path-to-artifact.jar you want to run. Then:
"java -jar path-to-artifact.jar" !
runs the command in SBT. You want to put the snippet above in a separate task, same as earlier.
And don't forget to reload when you change your project definition.
Couldn't you simply write the benchmarks as tests, so they will be run when you call 'test' in SBT?
You could also run a specific test with 'test-only', or run a main with 'run' or 'exec' (see http://code.google.com/p/simple-build-tool/wiki/RunningSbt for details).