Encoding issue when building with mvn

Question

I'm currently working on a Maven plugin that uses JAXB. The problem is that whether I launch a clean install in IntelliJ or in a console, I don't get the same results. JAXB is reading an XML file encoded in UTF-8, which contains special characters.

In IntelliJ, these characters are read without any problem. But in the console, these characters are replaced with '?' (I can see it if I do a sysout).

I found the source of my problem, but I don't really understand it and I don't know how to solve it: when IntelliJ runs mvn, it adds an extra parameter -Dfile.encoding=UTF-8

java -classpath /usr/share/maven/boot/plexus-classworlds-2.4.jar -Dclassworlds.conf=/usr/share/maven/bin/m2.conf -Dmaven.home=/usr/share/maven -Dfile.encoding=UTF-8 org.codehaus.plexus.classworlds.launcher.Launcher clean install

When I run mvn in command line, I can add this extra parameter but it will appear after the class name:

java -classpath /usr/share/maven/boot/plexus-classworlds-2.4.jar -Dclassworlds.conf=/usr/share/maven/bin/m2.conf -Dmaven.home=/usr/share/maven org.codehaus.plexus.classworlds.launcher.Launcher -Dfile.encoding=UTF-8 clean install

In both cases, if I sysout the content of System.getProperty("file.encoding"), I get the same value "UTF-8", but a different behaviour.

Of course I configured my pom.xml correctly using a property like this:

<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

I also tried to add a second property named "file.encoding" but it does not help.

My question is: why does the position of this system property change the behaviour of my program, and how can I fix my problem when I run mvn from command line?

Thanks in advance.

Your code that uses JAXB runs during Maven build, right? Also, why do you think that these characters are read incorrectly? Perhaps they just cannot be represented in console output. — axtavt, Feb 02 '12 at 17:02
Yes it runs during the Maven build. I am sure that these characters are read incorrectly because I use the objects unmarshalled by JAXB to produce output files. These files are correct when generated inside IntelliJ, but not correct when generated from the console. Also, if I run the correct command from the console I can see the correct characters in the console output :) — Bastien Jansen, Feb 02 '12 at 17:37

score 1 · Accepted Answer · edited May 23 '17 at 12:14

As suggested in other questions, the JVM starts with a default file encoding (usually the system file encoding) which is used every time Readers and Writers are used without an explicit encoding. Overriding the system property file.encoding at runtime does not change this behavior, you really have to specify -Dfile.encoding when starting the JVM if you want it to be the default encoding.

To fix my issue, I reused project.build.sourceEncoding in my Maven plugin (I had this problem in a custom plugin) to override file.encoding at runtime, and use this file.encoding to instantiate InputStreamReader and OutputStreamWriter with an explicit encoding as 2nd parameter.

As resources were correctly copied by the maven-resource-plugin in UTF-8, my problem was gone :D.

score 1 · Answer 2 · answered Feb 02 '12 at 18:23

Maybe try including this XML in your pom.xml file:

<project>
  [...]
  <build>
    [...]
    <plugin>
      <artifactId>maven-resources-plugin</artifactId>
      <version>2.4.3</version>
      <configuration>
        <encoding>UTF-8</encoding>
      </configuration>
    </plugin>

    <plugin>
      <artifactId>maven-compiler-plugin</artifactId>
      <version>2.3.2</version>
      <configuration>
        <source>1.6</source>
        <target>1.6</source>
        <encoding>UTF-8</encoding>
      </configuration>
    </plugin>
  </build>
</project>

I tried this but unfortunately it does not help. In fact I noticed that Maven was already using the right encoding, I can see it as an INFO log. I double checked the copied file in resources/, it's correct. The problem happens later, when my maven plugin reads the XML during the generate-sources phase. — Bastien Jansen, Feb 02 '12 at 21:16

Encoding issue when building with mvn

2 Answers2