I'm new to Scala and would like to do the DateTime using joda.
In Scastie (an online Scala IDE) I wrote this:
import org.joda.time.{DateTime}
But I got the error as the title.
I have the same error in my local IDE (IntelliJ). Please help me with this. Thank you.
You're trying to use something from this library: https://search.maven.org/artifact/joda-time/joda-time/2.10.13/jar
You can include this library in Scastie using the following line:
addSbtPlugin("joda-time" % "joda-time" % "2.10.13")
You can add this line by going to Build Settings in Scastie and entering the line in the Extra Sbt Configuration section.
Related
The SettingKey.~= method is used to exclude dependencies from libraryDependencies (see play 2.3.8 sbt excluding logback), but trying to find out what it does is hard as:
There is no documentation about this function at http://www.scala-sbt.org/0.13.12/api/index.html#sbt.SettingKey,
It cannot be searched using Google as it uses symbols in the method name and
Examination of the SBT source code (https://github.com/sbt/sbt/blob/0.13/main/settings/src/main/scala/sbt/Structure.scala#L47) does not provide an obvious answer.
Can anyone shed light on what this does?
someScopedKey ~= f
is equivalent to
someScopedKey := f(someScopedKey.value)
In other words, it transforms the previous value of the setting/task with a given function. That's literally all there is to know about it.
Spent a few hours trying to figure out how to do this. Over the course of it I have looked at a few seemingly promising questions but none of them seem to quite fit what I'm doing.
I've got three library jars, let's call them M, S, and H. Library M has things like:
case class MyModel(x: Int, s: String)
and then library S uses the play-json library, version 2.3.8, to provide implicit serializers for the classes defined by M
trait MyModelSerializer {
implicit val myModelFormt = Json.format[MyModel]
}
Which are then bundled up together into a convenience object for importing
package object implicits extends MyModelSerializer extends FooSerizlier // etc
That way, in Library H, when it performs HTTP calls to various services it just imports implicits from S and then I call Json.validate[MyModel] to get back the models I need from my web services. This is all well and dandy, but I'm working on an application that's running play 2.4 and when I included H into the project and tried to use it I ran up against:
java.lang.NoSuchMethodError: play.api.data.validation.ValidationError.<init>(Ljava/lang/String;Lscala/collection/Seq;)
Which I believe is being caused by play 2.4 using play-json version 2.4.6. Unfortunately, these are a minor version apart and this means that trying to just use the old library like:
// In build.sbt
"com.typesafe.play" %% "play-json" % "2.3.8" force()
Results in all the code in the app to fail to compile because I'm using things like JsError.toJson which weren't parts of play-json 2.3.8. I could change the 14 or so places trying to use that method, but given the exception before I have a feeling that even if I do that it's not going to help.
Around this point I remembered that back in my maven days I could shade dependencies during my build process. So I got to thinking that if I could shade the play-json 2.3.8 dependency in H that that would solve the problem. Since the problem seems to be that calling Json.* in H is using the Json object from play-json 2.4.6.
Unfortunately, the only thing I can find online that indicates the ability to shade is sbt-assembly. I found a great answer on how to do that for a fat jar. But I don't think I can use sbt-assembly because H isn't executable, it's just a library jar. I read through a question like my own but the answer refers to sbt-assembly so it doesn't help me.
Another question seems somewhat promising but I really can't follow how I would use it / where I would be placing the code itself. I also looked through the sbt manual, but nothing stuck out to me as being what I need.
I can't just change S to use play-json 2.4.6 because we're using H in a play 2.3 application as well. So it needs to be able to be used in both.
Right now the only thing I can really think to do if I can't get some kind of shading done is to make H not use S and to instead require some kind of serializer/deserializer implicitly and then wire in the appropriate json (dee)serializer. So here I am asking about how to properly shade with sbt with something that isn't an executable jar because I only want to do a re-write if I absolutely have to. If I missed something (like sbt-assembly being able to shade for non-executable jars as well), I'll take that as an answer if you can point me to the docs I must have missed.
As indicated by Yuval Itzchakov, sbt-assembly doesn't have to be building an executable jar and can shade library code as well. In addition, packing without transitive dependencies except the ones that need to be shaded can be done too and this will keep the packaged jar's size down and let the rest of the dependencies come through as usual.
Hunting down the transitive dependencies manually is what I ended up having to do, but if anyone has a way to do that automatically, that'd be a great addition to this answer. Anyway, this is what I needed to do to the H library's build file to get it properly shading the play-json library.
Figure out what the dependencies are using show compile:dependencyClasspath at the sbt console
Grab anything play related (since I'm only using play-json and no others I can assume play = needs shading)
Also shade the S models because they rely on play-json as well, so to avoid transitive dependencies bringing a non-shadded play 2.3.8 back in, I have to shade my serializers.
Add sbt-assembly to project and then update build.sbt file
build.sbt
//Shade rules for all things play:
assemblyShadeRules in assembly := Seq(
ShadeRule.rename("play.api.**" -> "shade.play.api.#1").inAll
)
//Grabbed from the "publishing" section of the sbt-assembly readme, excluding the "assembly" classifier
addArtifact(artifact in (Compile, assembly), assembly)
// Only the play stuff and the "S" serializers need to be shaded since they use/introduce play:
assemblyExcludedJars in assembly := {
val cp = (fullClasspath in assembly).value
val toIncludeInPackage = Seq(
"play-json_2.11-2.3.8.jar",
"play-datacommons_2.11-2.3.8.jar",
"play-iteratees_2.11-2.3.8.jar",
"play-functional_2.11-2.3.8.jar",
"S_2.11-0.0.0.jar"
)
cp filter {c => !toIncludeInPackage.contains(c.data.getName)}
}
And then I don't get any exceptions anymore from trying to run it. I hope this helps other people with similar issues, and if anyone has a way to automatically grab dependencies and filter by them I'll happily update the answer with it.
I know sbt console will open an interactive Scala REPL and load in all the library dependencies so people can test Scala code right there. However, I wonder if there's anyway to use and treat in a way so that people can interact with my programs directly, instead of interacting with libraries.
For example, if I write a Vector class, how can someone call it from sbt console or any other Scala REPL interface??
Think of it as that you are trying to write a Scala library but you want to provide a simple REPL interface for people to interact with it, like R, instead of asking people to add the library as dependency.
The effect is similar as described here: http://stanford-ppl.github.io/Delite/optiml/getting_started.html
Maybe this will help.
You can use initialCommands key in sbt to do this
So in build.sbt if you put
initialCommands in console := """import my.project._
val myObj = MyObject("Hello", "World")
"""
after you type 'console', you can start using myObj or the classes in my.project
http://www.scala-sbt.org/0.13.5/docs/Howto/scala.html#initial
Yes you can, but you cannot use modified code without reloading the REPL. Just run:
sbt "~ ; console"
And then import your classes with import your.package._ and use them from there.
If you make any changes to your library code, just hit CTRL+D or :quit and it will detect file changes, compile them and enter the REPL again. You can then use the history (navigating with the arrows up/down) to execute anything from the previous session again.
My first contact with Scala was through the SimplyScala tutorial: You don't need to install anything and can just start to code. After some hours I fell in love with the language...
Years later, I have written a web documentation for a Scala library as a Play Application. It would be cool to build something like SimplyScala and integrate it in the documentation, so that the user can enter Scala commands in the browser and get the result back.
SimplyScala works like LotREPLS (old Open-Source-Java-Project with just few LOCs) on the Google App Engine.
Is is also possible to create something like this on my own server without getting security holes (f.ex. the user should not read files from the server...)?
I just need the "base" of the Scala language without any imports just like in SimplyScala.
My first idea is to write an own SecurityManager and handle time-outs so that the user cannot consume too much server time. Is there any easier way or an existing open-source project?
Or is it just more rational to advice the user to install Scala and work with the terminal instead of the browser? ;-)
On the Scala homepage is a similar Play-project idea for the Summer of Code 2012 Scala Projects: but I cannot find any results.
Probably the most secure so far is http://www.scala-js-fiddle.com/ (code on GitHub) simply because it does not even run the code on the server, but on the client!
The gotcha is: it's not truly Scala code, it is Scala.js, which is a dialect of Scala, is still experimental, etc. But it might be enough for your use case.
Answering my own question:
Scala Consoles, that don't care about security (?):
Scala Web Console
Scala IDE
Tryscala
One web interface which handles somehow security:
The impressive Scalakata project, Source is on GitHub.
It's a Lift project that defines an own security manager (see src/main/scala/com.github.masseguillaume/security) and handle time-outs (see src/main/scala/com.github.masseguillaume/service/KateEval.scala). Now I have to think, if that is secure enough...
https://codebrew.io/ seems to work quite well as Scala REPL
code available at https://github.com/CodeBrew-io
with: libraryDependencies += "org.scala-lang" % "scala-compiler" % scalaVersion.value
Compiler (scala.tools.nsc.Global)
This is the most accurate method to evaluate scala code.
compileSources will add a new class in the classloader
usage
Repl
IMain
usage
JSR-223
import javax.script.ScriptEngineManager
val e = new ScriptEngineManager().getEngineByName("scala")
e.put("n", 10)
e.eval("1 + n") // 11
Reflection Toolbox
import scala.reflect.runtime.{currentMirror => cm}
import scala.reflect.runtime.universe._
import scala.tools.reflect.ToolBox
val tb = cm.mkToolBox()
tb.eval(tb.parse("1+1"))
// res0: Any = 2
Presentation (interactive) compiler (scala.tools.nsc.interactive.Global)
This is for autocompletion and other interactive features.
doc
usage
I'm having major problems getting Undercover to work using Maven
I'm using ScalaTest for unit tests and this is working perfectly
When I run Undercover though it simply creates empty files
I think it's probably a problem with the configuration in my pom.xml (but the documentation for Undercover is a little sketchy)
Help :)
Thanks
T
At one point I inquired about Emma on a Scala mailing list, and I was told that by some that they had more success with Cobertura. You might want to try that instead.
Up to what stage is this "working correctly", given that empty files are being produced?
Do you have a sample project/POM that demonstrates the problem?