I've created a svn repositoy on a linux server (Debian) and used a client on a windows machine to check my java sources in.
Now I've set up a Hudson server on a different linux server (Ubuntu) to periodically run tests on my code. But the tests fail with a compiler error:
Error: unmappable character for encoding ASCII
On my windows machine I've used the default encoding Cp1252.
On my svn server I can do a local checkout of my sources and they look good.
On my Hudson server the checkout contains illegal characters.
What are the parameters I have to adjust so that all three systems use a working encoding?
EDIT 2009-10-15:
I changed the default encoding of my Ubuntu system to latin1. Now I can open the checkedout files with an editor and they look good (thanks to #John-T at superuser.com).
But Hudson still complained about unmappable character for encoding ASCII and I found that this is caused by maven. I found an explantion, but the suggested solution didn't work. Now maven tells me that it uses latin1 when copying some resources, but the compiler (not using this setting?) still complains with the same error message.
No, the maven compiler plugin doesn't use the project.build.sourceEncoding property. So you need to configure the file encoding for it (I'd use UTF-8):
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<encoding>UTF-8</encoding>
</configuration>
</plugin>
The first thing to identify is which character is causing the problem. It may be that the broken char can be replaced by some pure-ASCII entity. SVN itself is encoding agnostic: it'll just store byte-for-byte what's passed in.
If Hudson requires 7-bit ASCII, then this is all you can do. Otherwise, find out what Hudson supports and save your files in this format instead. UTF-8 would probaby be the way to go.
I don't think there is a way to change the encoding of a file with SVN. You can set the encoding for a commit message with the --encoding flag, but not the contents of files themselves. Text files are stored in the same format they appear on your local disk. The only conversion is a translation of line endings according to the svn:eol-style property.
Related
I am seeing an issue with maven using Fbinfer using gitlab pipelines using linux runner
[WARNING] File encoding has not been set, using platform encoding
ANSI_X3.4-1968, i.e. build is platform dependent
[ERROR] /build/app/hello.java [43,43] error: unmappable charater
(0xE2] for encoding US-ASCII
Fbinfer maven command used:
/infer capture -- mvn clean compile
Pure ASCII is 7 bit only, meaning that characters above 127 are illegal. 0xE2 is a hexadecimal representation of 226 which is above 127, hence the error.
You need to tell which encoding system to use when interpreting the bytes. A common choice is ISO-Latin-1 - see https://cs.stanford.edu/people/miles/iso8859.html if it looks right to you
Then change in your Pom to reflect that. Look for “ascii” to see where.
Notice that keeping your project 7-bit clean is a good thing to avoid encoding issues.
I'm using OpenLiberty (automatically downloaded through its maven plugin) and my application is working fine (jax-rs and servlet/jsp outputs are fine).
But the console (and messages.log) output is messy. Here is one example:
[INFORMAıåES] SRVE0253I: [io.openliberty.microprofile.health.3.0.internal] [/health] [HealthCheckServlet]: Destrui?Æo bem sucedida.
(expected is [INFORMAÇÕES] ... Destruição bem sucedida.)
Clearly the messages are being printed as ISO-8859-1 in a UTF-8 capable terminal.
Again, this question is not about the application running inside OpenLiberty container, which is completely UTF-8 and working fine. It is about the console output.
A partially useful workaround would be to change its locale to en-US (so that OpenLiberty's messages wouldn't need any special character). Actually, I'd prefer english error messages, because they are easier to google for.
I already tried LANG=en-US.UTF8, LC_ALL=en_US and LC_MESSAGES=en_US, to no avail.
Project's effective pom.xml already declares <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>. Every file in my project is UTF-8. Project's .editorconfig [*] charset = utf-8 (so vscode creates every new file as utf-8).
I'm using bash MINGW64_NT-10.0-18363 + ConEmu-Maximus5 over Windows 10. LANG defaults to =pt_BR.UTF-8.
UPDATE
I've managed to set locale to en-US by adding
-Duser.language=en to ${server.config.dir}/jvm.options.
To be honest, I did it through liberty-maven-plugin:
<properties>
...
<liberty.jvm.language>-Duser.language=en-US</liberty.jvm.language>
...
</properties>
(and for liberty-maven-plugin itself, I've added -Duser.language=en to MAVEN_OPTS)
Unfortunately, -Dfile.encoding=UTF-8 did nothing.
UPDATE 2
I'm also running OpenLiberty inside an Arquillian driven junit test. Interestingly, when launched by arquillian, OpenLiberty honors the -Dfile.encoding=utf-8 setting.
For arquillian it could be configured through arquillian.xml:
<arquillian ...>
<container qualifier="liberty_managed" default="true">
<configuration>
...
<property name="javaVmArguments">-Dfile.encoding=utf-8</property>
...
</configuration>
</container>
</arquillian>
Or in ${server.config.dir}/jvm.options (as I did before):
-Dfile.encoding=utf-8
My conclusion is that -Dfile.encoding is the right way to approach this issue. But somehow when launched by liberty-maven-plugin it is not honored. I'll take a closer look into its source code.
UPDATED ANSWER: This is configurable via JVM options.
Note that in general the jvm.options file requires you to use a single option per line.
If want to use multiple options and use liberty-maven-plugin properties to configure them you could do something like:
<properties>
<liberty.jvm.arg1>-Duser.language=pt</liberty.jvm.arg1>
<liberty.jvm.arg2>-Duser.country=BR</liberty.jvm.arg2>
<liberty.jvm.arg3>-Dfile.encoding=utf-8</liberty.jvm.arg3>
</properties>
(Note that the arg1,arg2,arg3 suffixes don't really get used except to assign unique Maven project property names, but don't appear in the jvm.options file).
And your terminal program must have support for displaying these characters. E.g. for me using the Git Bash default terminal with default settings on a US/English install, the characters in the above Portuguese language config don't display unless click the Window icon then "Options" and add this:
I am using Ant to build a self deploying EXE for a JavaFX application.
Currently Inno Setup places the EXE here: C:\Users\username\AppData\Local\application name
I would like to place this in a different location, and provide the user the option to override this. However I can't seem to find the ant settings to change this.
Is this possible?
Thanks!
Actually you can't change this using ANT. However, as you already know the deploy mechanism uses Inno Setup and you can modify its behaviour.
During the fx:deploy ANT task a default ApplicationName.iss file is created. This default file contains e.g. the setting, which is responsible for the install directory. This default file is only created, if you don't provide any customized on your own. So, I would recommend to run the ANT script, copy the default file and modify it. If you enable the verbose flag of the fx:deploy task you can use the console output to find out, where the default file is created and where the ANT task searches for your customized file before creating the default one:
<fx:deploy
...
verbose="true">
<fx:info title="${appname}" vendor="${vendor}"/>
...
</fx:deploy>
In my case I found the default file in
C:\Users\gfkri\AppData\Local\Temp\fxbundler3627681647438085792\windows
and had to put the customized file to
package/windows/ApplicationName.iss
relative to the ANT build script.
If you got so far, you'll find the line DisableDirPage=Yes in your ApplicationName.iss file. Change it to DisableDirPage=No and the user gets the possibility to change the install directory.
Further you will find the parameter DefaultDirName. If you want to install your Application to C:\Program File\ApplicationName by default you can use the constant {pf} e.g.: DefaultDirName={pf}\ApplicationName.
The original answer is not true anymore, because that feature got added to the JDK (just dont know when, but it was there when using 1.8.0u60 or so).
Just add <installdirChooser> as some <bundleArguments> and set it to true:
<plugin>
<groupId>com.zenjava</groupId>
<artifactId>javafx-maven-plugin</artifactId>
<version>8.4.0</version>
<configuration>
<mainClass>your.mainclass</mainClass>
<verbose>true</verbose>
<bundleArguments>
<identifier>SOME-GUID-USED-FOR-UPDATE-DETECTION</identifier>
<installdirChooser>true</installdirChooser>
</bundleArguments>
</configuration>
</plugin>
Disclaimer: I'm the maintainer of the javafx-maven-plugin
I am getting this error when trying to build the spring.io/sagan project on GitHub from wiki steps.
java.lang.AssertionError:
Expected: "Spring Tool Suiteâ„¢ Downloads"
but: was "Spring Tool Suite™ Downloads"
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8)
at sagan.tools.support.ToolsPagesTests.showsAllStsGaDownloads(ToolsPagesTests.java:59)
I have tried building through msyGit bash, and through windows CLI without any difference.
I have tried running the site. It builds to 93%. I can browse the site but the site looks like plain HTML without CSS or images.
I have been told its an encoding issue but how to fix this?
It looks like it expects UTF8 but the encoding is ASCII.
Before building I have also tried to change the windows CLI encoding with the following advice:
Unicode characters in Windows command line - how?
But it has not made a difference. I am running windows 8.1
Not tested, but the problem probably comes from the fact that no encoding has been specified to the compiler for the Java files, and the sagan developers probably use a MacOS or Unix machine, whose default file encoding is UTF8, whereas the default encoding is different on Windows.
I would try adding the following lines to the root build.gradle file, inside the configure(javaProjects) section, after the java plugin has been applied:
configure(javaProjects) {
apply plugin: 'java'
// configure encoding to UTF8:
tasks.withType(Compile) {
options.encoding = 'UTF-8'
}
If that solves the problem, you should file a bug report, or even a pull request to the project.
I have generated a bunch of java-files from a WSDL source. I used Apache CXF 2.6.1 for generating the files.
When I put the code onto our production box that is running jetty and maven and I send a request to the server via the generated java-files it somehow changes the systems/JVM character encoding. The swedish characters å, ä and ö changes into Ã¥, ä, ö.
I can't reproduce this on my own box.
Someone have any idea?
Since version 2.5.4 there is a new command line option -encoding which is not yet documented on the official documentation. But when you call the tool with the help option (-h|-help) you will see the encoding option:
wsdl2java ... -encoding UTF-8 ....