Assuming I didn't mess up the config (you can see the execution at the beginning of the console output) it seems to be running without any errors so far.
Hm, both theory and practice tell me that reading ASCII files with UTF-16 encoding is a rather bad idea, so the build must fail if properly configured. After some investigation, it appears that my initial suggestion to simply set MAVEN_OPTS does not really work. For example, from the Surefire XML report [0] I read <property value="ANSI_X3.4-1968" name="file.encoding"/> so Maven is still using ASCII. One part of this problem could be all the process forking done during the tests: If I count properly, there is one fork by Surefire for the whole suite and one additional fork once per Maven invocation by the Verifier. The challenge is to get the -Dfile.encoding setting down all this road. The MAVEN_OPTS var simply isn't pushed through all the sub environments. What I could not figure out is why the root invocation of maven/2.0./bin succeeded in the first place. That invocation should have respected the exported MAVEN_OPTS var and as such should have broke immediately due to PLX-367. Is the build using a customized run script that does not care about MAVEN_OPTS? Just curious, in the end it's quite desirable to have the root Maven process use a safe environment/encoding since we really want to test the other Maven executable. Benjamin [0] https://ci.sonatype.org/job/Maven-2.0.x-ITs-UTF-16/ws/maven-core-its/target/surefire-reports/TEST-org.apache.maven.its.Suite.xml --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
