I have a very similar issue as sbt test encoding hickup but since the answer does not apply and my case is in Scala code I ask here.
I have a string containing non ASCII characters in a unit test. This test is working fine on Linux, and fine on Windows when run from IntelliJ. However, when run from a Windows shell with sbt test they fail. If I print the string humanité it is displayed as humanitΘ in the failing case. The file encoding is UTF-8.
println(new java.io.InputStreamReader(System.in).getEncoding) returns UTF8 when run from IntelliJ, and Cp1252 from the shell. I tried various things to change the encoding:
run sbt "-Dfile.encoding=UTF-8" test
check that scalacOptions defined in my build.sbt contains "-encoding", "UTF8"
But the default encoding is always Cp1252 (maybe that's normal?) and the test keeps failing.
The failing code is the following:
val stringToEncrypt = "l'humanité"
println(test)
From IntelliJ I get:
l'humanité
From a windows shell running sbt:
l'humanitΘ
In order to avoid problems with default charset for OS, you can pass explicitly the desired charset when creating the InputStream:
new java.io.InputStreamReader(System.in,"UTF-8")
Related
I've recently installed Scala as a part of my functional programming course and I've encountered a problem: IntelliJ IDEA 2017.2.1 (Java version 9, build 9+181) doesn't run any of my scala code, exitting with
Error: Could not find or load main class Main
This code is an example.
object Main {
def length[A](list:List[A]):Int = {
if (list == Nil) 0
else 1 + length(list.tail)
}
def main(args: Array[String]): Unit = {
length(List[Int](1, 4, 5, 12, -1))
}
}
It's really simple, yet IntelliJ refuses to run it. Windows CMD doesn't even react to a scala command, resulting into
'scala' is not recognized as an internal or external command,
operable program or batch file.
even though I have it installed on my computer. If I call Scala Console inside of IntelliJ everything works fine and compiles as expected. I've tried switching to JDK 1.8 inside of IntelliJ, yet it led to no result.
What could be the problem?
For me it turns out that the src/main was not marked as Sources Root
which causes the following error
...
One of the two will be used. Which one is undefined.
Error: Could not find or load main class Main
Process finished with exit code 1
So of course after I mark the src/main as Sources Root, the Scala Hello World example runs happy again.
Notice the blue color of directory src/main when it's marked as Sources Root
Are you using the little green arrow to run the program from inside of your Main object?
How did you create the program? It could be that your build file SBT configuration of the project is a different Scala version than what's installed on your computer.
It's really simple, yet IntelliJ refuses to run it. Windows CMD
doesn't even react to a scala command, resulting into
'scala' is not recognized as an internal or external command, operable program or batch file.
This means that Scala is not added to your class path in your terminal. Look up how to do that and see if that doesn't help out your IntelliJ problem too.
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'...
I tried
val cmd = sys.process.Process(Seq("C:\apache-ant-1.9.3\bin\ant", "everythingNoJunit"), new java.io.File(scriptDir))
cmd.lines
and got this error:
CreateProcess error=193, %1 is not a valid Win32 application
How do I run the ant script from within scala app?
The basic answer is that your should be using "ant.bat" instead of "ant" on a windows machine as in this answer
In addition to that, I would suggest using a non-windows styled path so you don't have to escape the backslashes:
val cmd = sys.process.Process(Seq("/apache-ant-1.9.3/bin/ant.bat", "everythingNoJunit"), new java.io.File(scriptDir))
Using this approach, I'm able to run an an ant target successfully when my scala application is also in "c:".
I'm running Scala 2.10 program through sbt run from Windows 7 command line and I see an unexpected behavior while calling readLine overload with the prompt. The prompt is shown after the actual line input.
Source
object MyExample extends App {
readLine("This prompt is shown after the readline!")
}
build.sbt
name := "hello"\n
\n
version := "1.0"\n
\n
Output
asdf
This prompt is shown after the readline!
Is there something I don't understand or is it a bug? It seems to be working as expected from IDEA.
Sbt version: 0.13.1
I've run into this before with giter8. The work around is to do your own print, flush the output stream, and then read. See this pull request for an example of the workaround.
Someone has fixed it in the scala source about a month ago. I don't have any idea when we will see that fix, tho.
I'm using infinitest in Eclipse and I have a strange phenomenon in connection with JUnit.
I have code that uses org.apache.http.HttpResponse.getEntity() and org.apache.http.entity.StringEntity. The JUnit test looks like this:
#Test
public void convertEncodedContentToString() throws UnsupportedEncodingException {
HttpResponse httpResponseMock = Mockito.mock(HttpResponse.class);
Mockito.when(httpResponseMock.getEntity()).thenReturn(new StringEntity("huiäöüß#€", HTTP.UTF_8));
Assert.assertEquals("huiäöüß#€", parser.convertContentToString(httpResponseMock));
}
All source files are stored in UTF-8.
If I let JUnit execute this method, it works fine.
However, if infinitest runs this test it complains that the assertion fails.
ComparisonFailure (expected:<hui[äöüß#€]> but was:<hui[äöüß#€]>) in ResponseBodyParserFactoryTest.convertEncodedContentToString
Obviously there is a character encoding problem.
As infinitest has close to no options I have no idea how to help infinitest to run this test properly. Can anyone please help me out here?
You need to say to infinitest that it must use the UTF-8 charset to run the tests.
Just add a file in your Eclipse project: "infinitest.args".
In this file, add the following:
-Dfile.encoding=UTF-8
And so, inifinitest will use UTF-8
User guide: http://infinitest.github.com/doc/user_guide.html specifically the 'Setting JVM Options' section