I'm trying to add a 3rd party jar to my java library path. If I invoke sbt with -Djava.library.path=a-3rd-party-lib.jar, then it works for the first invocation of run-main MyClass inside sbt, but thereafter the 3rd party code complains that the jar is not in the java library path. I have also tried adding javaOptions += "-Djava.library.path=a-3rd-party-lib.jar" to my build.sbt file, but this hasn't worked (even for the first run). Qualifying this command as javaOptions in (Test,run) += "-Djava.library.path=a-3rd-party-lib.jar" (as seen in the docs) hasn't worked either.
Am I doing something wrong, or is this a strange bug?
FYI I'm using sbt 0.13.0
javaOptions only takes effect if you fork run and sbt does not fork by default. See the Forking documentation for details, but forking is enabled for run and runMain with:
fork in run := true
Related
When I had a single-part project, from the command line I could say:
sbt testOnly *.FooSpec
Now that I have a multi-part project, that same command returns nothing--it can't find FooSpec. Imagine FooSpec lives in a subproject called 'part'. How can I specify 'part' in my sbt command? I tried:
sbt testOnly part:*.FooSpec
Didn't work.
(btw, I know I can do 'project part' then 'testOnly *.FooSpec' from inside sbt. I want to do this all from the shell, not inside sbt)
I am migrating from activator from 0.13.x to sbt 1.x.
I used to compile my modules like this $ activator clean compile publish-local -Dversion=1
Now, I am trying to do it with sbt since activator has been deprecated, but I can not find how I should migrate to something similar like $ sbt clean compile publish-local -Dversion=1?
Activator (the CLI part) was just a wrapper around sbt with some custom commands. So what you wrote should work the same, expect that the snake-case was deprecated in favor of the camelCase:
sbt clean compile publishLocal
If you need to pass a var to the Java runtime with -D you have to place it before any commands: sbt -Dversion=1 ....
Notice that you use batch mode to run the commands:
Running in batch mode requires JVM spinup and JIT each time, so your build will run much slower. For day-to-day coding, we recommend using the sbt shell or Continuous build and test feature described below.
To follow this recommendation, just run sbt and then enter those commands one by one. Or to run them all sequentially, enter ; clean; compile; publishLocal.
In Gradle, there is a concept of a buildscript dependency, in that you can add an external dependency that the build script depends on to run. This is similar to SBT's plugins, except way more lightweight. With Gradle, I can add X as a dependency and then write Groovy code using the contents of X. I need to use an external Java library inside of my build script and the mechanisms to do this are far from obvious to me in SBT.
With SBT, the closest thing I've found in the documentation is addSbtPlugin, which works great if there is an X SBT plugin, but it isn't in this case.
Sbt builds are recursive, you can add a project/build.sbt file then add libraryDependency += ... to it.
The goal is to have a standalone Play Framework (2.2) application having an additional status window open containing some javafx (javafx-8) elements.
Since JavaFX classes are now on the default runtime classpath for an Oracle Java 8 implementation using javafx.* in my classes and compiling with sbt should just be fine.
However sbt can't find these classes and quits with
play.api.UnexpectedException: Unexpected exception[NoClassDefFoundError: javafx/application/Application]
when executing
..\path-to-play-framework-2.2\play project run
The best way to fix this problem seems to be the modification of build.sbt in the project directory. What can I do to add the missing (class) path?
Sadly JavaFX doesn't link that easily to an sbt build. You need to set your JAVA_HOME environment variable and do modifications to your build file.
Here I have a repository where this is set up. The important bit if you are using an sbt build rather than a scala build is this one:
unmanagedJars in Compile += Attributed.blank(
file(System.getenv("JAVA_HOME") + "/jre/lib/jfxrt.jar")),
fork in run := true
The reason for this is that jfxrt.jar is the archive containing the JavaFX runtime and it is not included in the classpath of an sbt project by default.
Anotherway is to set the Classpath for sbt. This can be done on the machines which can't resolve JavaFX.
SBT_OPTS="-Xbootclasspath/p:/usr/share/java/openjfx/jre/lib/ext/jfxrt.jar"
I am pulling my hair using the sbt-jflex plugin to generate Java sources via JFlex, before the main javac phase of sbt (0.12).
The plugin is a clone of the ANTLR plugin, and I found this question which shows how to use the latter.
So I have the following in project/plugins.sbt:
addSbtPlugin("org.scalanlp" % "sbt-jflex" % "0.1-SNAPSHOT")
And this in ./build.sbt:
jflexSettings
sourceGenerators in Compile <+= generate in jflex
But I must be either doing something wrong, or the javac phase comes before the source generators, because when I run sbt compile, I never see the message "JFlex: Using JFlex version X to generate source files". Instead sbt goes straight to compile the Java sources
[info] Compiling 91 Java sources to ...
And then fails because the JFlex output is missing at that stage. Running source-directories shows that src/main/jflex is indeed included, as is target/src_managed/main.
After playing around with injecting debug prints, I found that the sbt-jflex plugin assumes sources are in src/main/flex whereas my project has them in src/main/jflex. Adding the following fixes it:
sourceDirectory in jflex <<= (sourceDirectory in Compile) { _ / "jflex" }