At the moment Gradle's scala integration does not offer REPL functionality. How to ergonomically run a Scala REPL from Gradle with the appropriate classpath?
Minimal build.gradle:
apply plugin: 'scala'
repositories{
mavenCentral()
}
dependencies{
compile "org.scala-lang:scala-library:2.11.7"
compile "org.scala-lang:scala-compiler:2.11.7"
}
task repl(type:JavaExec) {
main = "scala.tools.nsc.MainGenericRunner"
classpath = sourceSets.main.runtimeClasspath
standardInput System.in
args '-usejavacp'
}
Credit to this answer for explaining how to direct stdin with standardInput and have REPL use the right classpath with args.
Notice the scala-compiler library is a dependency. That's where scala.tools.nsc.MainGenericRunner is found.
From the console a number of options are needed to run the REPL:
--no-daemon, if you are using a Gradle daemon. At the moment, the REPL does not respond to keystrokes if run from the daemon.
--console plain. A popular, but inferior alternative is --quiet. If run without one of these options, REPL's prompt is contaminated by Gradle's progress report. --console plain has the advantage that it also adjusts readline's behaviour so that rlwrap is unnecessary.
Full command to run the REPL is gradle repl --console plain --no-daemon, so creating an alias in your shell makes sense.
Related
is there a way to build/compile all configurations at once? I have a project that has a Dev configuration in addition to the default Compile and Test configuration, and i am looking for a command or a setting in my build.sbt that would allow me to compile/package all 3 configurations at once.
Basically looking for a way to avoid having to do these 3 commands to build the entire source tree:
sbt compile
sbt dev:compile
sbt test:compile
When I use sbt from IntelliJ it is able to do this on building the project, but I am looking to do this from the command line.
First, you can run multiple tasks with a single sbt invocation:
sbt compile dev:compile test:compile
Second, you could define an alias in your build which does what you want:
addCommandAlias("compileAll", "; compile; dev:compile; test:compile")
Then, just run sbt compileAll.
I am working on a scala project which uses sbt for build tools. When we run unit tests on command line 'sbt test', the tests are running fine. However, when I run unit tests in IntelliJ, it seems to be picking up incorrect version of a dependency as well.
I was wondering if there is a way for me to print the classpath that IntelliJ is running the unit tests with?
IntelliJ IDEA already does that, actually, for each test run.
Tests are run as an invocation of JVM with the classpath passed to command-line parameter.
You need to press on the ellipsis to see the whole command line.
Classpath will be there after -classpath argument.
It's better to copy it to another window and enable line wrapping for the further digging.
These simple lines in build.gradle expose a repl task that would ideally fire up a scala REPL. Fire up and keep alive that is. After the repl loads, it immediately receives a :quit command and exits.
Important parts of build.gradle:
dependencies{
compile "org.scala-lang:scala-library:2.11.7"
compile "org.scala-lang:scala-compiler:2.11.7"
}
task repl(type:JavaExec) {
main = "scala.tools.nsc.MainGenericRunner"
classpath = sourceSets.main.runtimeClasspath
}
Launching the REPL:
% gradle repl
:compileJava UP-TO-DATE
:compileScala UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:repl
Welcome to Scala version 2.11.7 (OpenJDK Server VM, Java 1.7.0_91).
Type in expressions to have them evaluated.
Type :help for more information.
scala> :quit
BUILD SUCCESSFUL
Total time: 31.177 secs
REPL quits automatically immediately after launching. How to not have the REPL quit immediately?
You also need to redirect console input to your javaexec java process. Try adding standardInput System.in to your task definition. In my case, I also found it necessary to add args '-userjavacp'.
task repl(type:JavaExec) {
main = "scala.tools.nsc.MainGenericRunner"
classpath = sourceSets.main.runtimeClasspath
standardInput System.in
args '-usejavacp'
}
and finally running gradle with the -q option suppresses the gradle progress prompts giving me a cleaner scala repl.
When your project doesn't compile, can you start a Scala REPL in SBT? using sbt console SBT seems to first compile the project and exit in this case. However the console could help experiment for solving the compilation trouble....
consoleQuick is an SBT task that starts a REPL with the same classpath as console but without forcing compilation. (It is described alongside similar tasks by the sbt tasks command).
How can I run an sbt app from the shell, so that I can run my app as a normal command-line program (as if run directly via scala but without having to set up an enormous classpath)?
I know I can do:
echo hello | sbt 'run-main com.foo.MyMain3 arg1 arg2' > out.txt
But this (1) takes forever to start because it starts sbt, (2) causes all stdout and stderr to go to stdout, and (3) causes all output to be decorated with a logger [info] or [error].
I looked at https://github.com/harrah/xsbt/wiki/Launcher but it seems too heavyweight, since it downloads dependencies and sets up a new environment and whatnot. I just want to run this app within my existing development environment.
Thus far I've cobbled together my own script to build up a classpath, and you can also do some other things like modify your project file to get sbt to print the raw classpath, but I feel like there must be a better way.
Here's what I have in my SBT (version 0.10) project definition,
val Mklauncher = config("mklauncher") extend(Compile)
val mklauncher = TaskKey[Unit]("mklauncher")
val mklauncherTask = mklauncher <<= (target, fullClasspath in Runtime) map { (target, cp) =>
def writeFile(file: File, str: String) {
val writer = new PrintWriter(file)
writer.println(str)
writer.close()
}
val cpString = cp.map(_.data).mkString(":")
val launchString = """
CLASSPATH="%s"
scala -usejavacp -Djava.class.path="${CLASSPATH}" "$#"
""".format(cpString)
val targetFile = (target / "scala-sbt").asFile
writeFile(targetFile, launchString)
targetFile.setExecutable(true)
}
... // remember to add mklauncherTask to Project Settings
The mklauncher task creates a script target/scala-sbt that executes scala with the project classpath already set. It would be nice to have mklauncher executed automatically whenever the classpath changes, but I haven't looked into doing this yet.
(I use the Java classpath, rather than Scala's, for ease of creating embedded interpreters.)
The start-script SBT plugin is now at:
https://github.com/sbt/sbt-start-script
It requires a few steps to set up and generates scripts that do not work on OS X, but that can be easily fixed if you're on that platform (see below).
Setup
Install greadlink (OS X only):
a) brew install coreutils
b) map readlink to the new function (greadlink) by adding these lines to ~/.bashrc:
function readlink() { greadlink "$#"; }
export -f readlink`
Add start-script plugin to ~/.sbt/plugins/build.sbt:
addSbtPlugin("com.typesafe.sbt" % "sbt-start-script" % "0.8.0")
Add start-script task to current project:
$ sbt add-start-script-tasks # execute from directory where build.sbt resides
Add start-script support to current build.sbt:
import com.typesafe.sbt.SbtStartScript
seq(SbtStartScript.startScriptForClassesSettings: _*)
Note the blank line in between statements (de rigueur for SBT build files).
Generate Start Script
Then, whenever you want to create a script to start your app like sbt run-main, but without sbt, execute:
$ sbt start-script
Run
target/start mypackage.MyMainClass
Time flies by and a lot have changed since the other answers. It's currently SBT 0.13.6 time.
I think what you may need is the sbt-onejar plugin or the SBT Native Packager plugin.
sbt-onejar "is a simple-build-tool plugin for building a single executable JAR containing all your code and dependencies as nested JARs."
SBT Native Packager's "goal is to be able to bundle up Scala software built with SBT for native packaging systems, like deb, rpm, homebrew, msi."
Just discovered the sbt start script plugin: https://github.com/typesafehub/xsbt-start-script-plugin:
This plugin allows you to generate a script target/start for a
project. The script will run the project "in-place" (without having to
build a package first).
The target/start script is similar to sbt run but it doesn't rely on
SBT. sbt run is not recommended for production use because it keeps
SBT itself in-memory. target/start is intended to run an app in
production.
The plugin adds a task start-script which generates target/start. It
also adds a stage task, aliased to the start-script task.