Can SBT work with jMockit? - sbt

After many struggles I finally got a large project converted over from Maven to SBT. One of the remaining issues, however, is that some of the unit tests in the project use jMockit which can be a bit high-maintenance when it comes to configuring the environment.
Specifically the jmockit dependency/jar has two difficult requirements:
The jmockit jar must appear in the classpath before the junit jar
On many JVM's, such as the OpenJDK one I'm using, the JVM argument -javaagent:<path/to/jmockit.jar> is required
If both of these conditions are not met, I'm faced with the error:
[error] Test <mytestclass>.initializationError failed: java.lang.Exception: Method <mytestmethod> should have no parameters
[error] at mockit.integration.junit4.JMockit.<init>(JMockit.java:32)
I think I eventually managed to take care of #1 with SBT but I'm still having trouble with the second one. The debug SBT logs do not show enough detail about the forked process invocation to tell me if my settings are working or not. But the test output consistently indicates that it's not working. I have what I think are all the relevant settings:
lazy val myproj = Project(
...
settings = otherSettings ++ Seq(
libraryDependencies ++= Seq(
"com.googlecode.jmockit" % "jmockit" % "1.7" % "test",
"junit" % "junit" % "4.8.1" % "test"
),
fork in Test := true,
javaOptions in test += "-javaagent:<hardcode-path-to-jmockit.jar>"
)
I think the classpath is OK based on the output of the test:dependencyClasspath:
sbt> project <myproject>
sbt> show test:dependencyClasspath
[info] List(...., Attributed(/var/build/ivy2/cache/junit/junit/jars/junit-4.8.1.jar), ...
..., Attributed(/var/build/ivy2/cache/com.googlecode.jmockit/jmockit/jars/jmockit-1.7.jar), ...)
So I'm thinking that my javaagent setting is not having the intended result.
If I do happen to get this to work, my next question is how to get the hard-coded jmockit.jar path out of there but for now I'll settle for a passing test case.
So, how do I set the JVM options used for testing? How do I view/verify what options are actually used when the tests are launched?

You need to change your javaOptions to javaOptions in Test (note the T in Test is capitalized).
You can check your options by executing show test:javaOptions
> show test:javaOptions
[info] List(-javaagent:/home/lpiepiora/.ivy2/cache/com.googlecode.jmockit/jmockit/jars/jmockit-1.7.jar)
Additionally if you want to use dynamic path to the jmockit jar, you can set your javaOptions like this:
def jmockitPath(f: Seq[File]) = f.filter(_.name.endsWith("jmockit-1.7.jar")).head
javaOptions in Test += s"-javaagent:${jmockitPath((dependencyClasspath in Test).value.files)}"
build.sbt for reference
libraryDependencies += "com.novocode" % "junit-interface" % "0.9" % "test"
libraryDependencies ++= Seq(
"com.googlecode.jmockit" % "jmockit" % "1.7" % "test",
"junit" % "junit" % "4.8.1" % "test"
)
fork in Test := true
def jmockitPath(f: Seq[File]) = f.filter(_.name.endsWith("jmockit-1.7.jar")).head
javaOptions in Test += s"-javaagent:${jmockitPath((dependencyClasspath in Test).value.files)}"

Related

How to use SBT's libraryDependencyScheme key

I'm in library dependency hell right now with the following error:
[error] (server / update) found version conflict(s) in library dependencies; some are suspected to be binary incompatible:
[error]
[error] * com.lihaoyi:geny_2.13:1.0.0 (early-semver) is selected over 0.6.10
[error] +- com.lihaoyi:scalatags_2.13:0.12.0 (depends on 1.0.0)
[error] +- com.lihaoyi:fastparse_2.13:2.3.3 (depends on 0.6.10)
[error]
[error]
[error] this can be overridden using libraryDependencySchemes or evictionErrorLevel
I'm still stymied by how to use libraryDependencySchemes, as the error message suggests.
A search for libraryDependencySchemes in the SBT documentation comes up empty.
Preventing Version Conflict with VersionScheme is aimed primarily at library authors, not users. It has a short section at the end for users, but focuses on how to impose a dependency scheme when the library author has not. There's only one example, how to impose early-semver if the library author has not:
ThisBuild / libraryDependencySchemes += "io.circe" %% "circe-core" % "early-semver"
From elsewhere (e.g. this sbt issue) I gather that replacing "early-semver" in the above with "always" or VersionScheme.Always is
the correct way to specify "don't check the version compatibility of this library"
Unfortunately, that hasn't worked for me -- I get the same error.
The build for this project has several subprojects. Here's the relevant part of the build. Can anyone explain what's wrong and why?
lazy val xplatform = crossProject(JSPlatform, JVMPlatform)
.crossType(CrossType.Full)
.in(file("_xplatform"))
.settings(commonSettings)
.settings(
libraryDependencySchemes += "com.lihaoyi" %% "geny" % VersionScheme.Always, // "early-semver",
libraryDependencies ++= Seq(
"com.lihaoyi" %%% "fastparse" % "2.3.3",
"com.lihaoyi" %%% "scalatags" % "0.12.0",
// some additional libraries omitted for brevity
),
jsEnv := new org.scalajs.jsenv.jsdomnodejs.JSDOMNodeJSEnv()
)
.jsSettings(
libraryDependencies ++= Seq(
"ca.bwbecker" %%% "jsFacadeOptionBuilder" % "0.9.6"
),
jsDependencies += "org.webjars" % "jquery" % "3.4.1" / "jquery.js" % "test"
)
.jsConfigure(_.enablePlugins(ScalaJSWeb, JSDependenciesPlugin))
Update:
After further testing, I realize that this is only occurring on the ScalaJS side of the project.
I've tried both of the following; no difference on the JVM side but neither work for ScalaJS.
libraryDependencySchemes += "com.lihaoyi" %% "geny" % VersionScheme.Always, // "early-semver",
libraryDependencySchemes += "com.lihaoyi" %%% "geny" % VersionScheme.Always, // "early-semver",
Turns out this is an SBT bug (as of 2023-01-26). Using
libraryDependencySchemes += "com.lihaoyi" %% "geny" % VersionScheme.Always
suppresses the error in a JVM-only build file. It doesn't work for anything involving Scala.JS.
See my bug report for a small working example (on the JVM) and failing (on Scala.JS).

SBT dependencyOverrides in a scope doesn't seem to work as expected

I would like to have a different version of library in test scope.
I was hoping the simplified version of project descriptor could look like that.
Please mind it's a simplified view, in my real project it's more convoluted. I need to use dependencyOverrides to enforce certain library version.
import sbt._, Keys._
organization := "me"
name := "test"
version := "0.1"
libraryDependencies := Seq("ch.qos.logback" % "logback-classic" % "1.2.3")
dependencyOverrides := Seq(
"ch.qos.logback" % "logback-classic" % "1.2.2"
)
dependencyOverrides in Test := Seq(
"ch.qos.logback" % "logback-classic" % "1.2.1"
)
I'd be hoping to see logback-classic version 1.2.1 when I run:
show test:managedClasspath.
Instead I get logback-classic version 1.2.2 as if dependencyOverrides in Test was ignored.
At the same time when I run show Test/dependencyOverrides I get the expected result which is:
ch.qos.logback:logback-classic:1.2.1
Does anyone has a clue what am I missing in the relation between dependencyOverrides in Test scope and managedClasspath?
It appears the problem cannot be solve the way I imagined. The main reason is libraryDependencies and update are not scoped to configuration.
I think the best solution is in case I need a different version of library in some tests to extract those tests to a separate module with independent set of libraryDependencies.

What is the meaning of 4th `%` in `libraryDependencies`in sbt

In the following setting, I suppose the format is "groupId" % "artifactId" % "version"
libraryDependencies += "org.specs2" % "specs2_2.10" % "1.14" % "test"
What does test mean?
As described here
Declaring a dependency looks like this, where groupId, artifactId, and revision are strings:
libraryDependencies += groupID % artifactID % revision
or like this, where configuration can be a string or Configuration val:
libraryDependencies += groupID % artifactID % revision % configuration
So the 4th % meaning is to add a dependency only to a certain configuration. In your example it is "test", which could also be written as Test.
The meaning is that you don't usually need to keep in your runtime classpath classes for test framework which you only use in staging environment and never use in production.
To learn more about configurations you can read this.

What does "provided->default" mean in an sbt build file?

An example of this comes from a sample github project:
libraryDependencies ++= Seq(
"javax.servlet" % "servlet-api" % "2.5" % "provided->default",
...
}
I'm only vaguely clear on what the 'fourth column' in these configurations mean, but this is the first time I've seen either provided or provided->default, and it's unclear how I can go about finding what should be expected here in the documentation. Can anyone help explain this construct?
It means that your provided configuration depends on the default configuration of "java.servlet" % "servlet-api" % "2.5".
Maven scopes describe what these configurations or scopes mean.
For instance, if you're using a library to write your tests, you've probably come across something like "org.scalacheck" %% "scalacheck" % "1.13.2" % "test" or similar. Here, the second part of the configuration is omitted and refers to the default configuration (usually compile). Equivalently, you could write "org.scalacheck" %% "scalacheck" % "1.13.2" % "test->compile". It means that your test configuration depends on the default configuration of ScalaCheck: your tests need ScalaCheck on the class path to compile and run.
You may find more details in the Ivy documentation.

akka-http not showing metrics in NewRelic

I'm trying to monitor my akka-http Rest web-service with NewRelic
The application has only one GET url (defined with akka-http)
I have the following configuration in the plugins.sbt
logLevel := Level.Warn
addSbtPlugin("com.typesafe.sbt" % "sbt-native-packager" % "1.0.4")
addSbtPlugin("com.gilt.sbt" % "sbt-newrelic" % "0.1.4")
I have the following configuration in the build.sbt
scalaVersion := "2.11.7"
name := "recommender-api"
...blablabla...
libraryDependencies += "com.typesafe.akka" % "akka-actor_2.11" % "2.4.2"
libraryDependencies += "com.typesafe.akka" % "akka-http-experimental_2.11" % "2.4.2"
libraryDependencies += "com.typesafe.akka" % "akka-http-spray-json-experimental_2.11" % "2.4.2"
libraryDependencies += "com.typesafe.akka" % "akka-slf4j_2.11" % "2.4.2"
newrelicIncludeApi := true
newrelicAppName := name.toString
enablePlugins(JavaServerAppPackaging, UniversalDeployPlugin, NewRelic)
I compile (and deploy) the code with sbt universal:publish, it creates a .zip, inside the .zip there is an executable file.
I pass the newRelic licenceKey by enviroment (NEW_RELIC_LICENSE_KEY)
The program starts and all works fine, the newRelic key is found (because the log dosen't say that it didn't find the key)
The aplication apears in the newRelic monitor system with the correct name
BUT NewRelic dosen't show any metrics
what I have to do to see some metrics on NewRelic?
When you specify the value of newrelicAppName as name.toString, you are not doing what you expect.
name is a value of type sbt.SettingKey, this contains details of a setting's name, type, and a short description of what the key is used for.
The type that actually contains a value is an sbt.Setting. You can get a Setting from a SettingKey (in the current project and configuration) by calling the .value method.
So when you set the value like this:
newrelicAppName := name.toString
the value looks something like this:
$ show newrelicAppName
[info] sbt.SettingKey$$anon$4#54ec2887
Yes, that is actually a string containing lots of strange characters.
On the other hand, if you used the .value call:
newrelicAppName := name.value
the value then looks like:
$ show newrelicAppName
[info] my-project
My best guess is that New Relic doesn't like application names with strange characters (like dollar signs and ampersands). By setting a more normal string, you made it more likely that New Relic would accept such a name as input.
Note: the default value for newrelicAppName is the name for the containing project, so not setting the value at all in the first example would probably have "just worked" as you would have liked.
I realy don't know what I did to make it work, the changes I made were:
In the build.sbt
newrelicVersion := "3.26.1"
newrelicAppName := "recommenders-jobs-api-monitor"
In the plugin.sbt
addSbtPlugin("com.gilt.sbt" % "sbt-newrelic" % "0.1.5")
(I updated de sbt-newrelic version)
(I harcoded the name of the new relic app)
(I specified the version of the Java Agent)

Resources