it should fail as soon as testitMNG3473 (the second test actually) I copied the shell script used by Hudson to launch tests on my machine and tried it: same problem as the CI server, the IT tests don't fail
I think I found the cause: - I already have a MAVEN_OPTS environment variable - Hudson sets the new variable in 2 steps: "set MAVEN_OPTS=..." then "export MAVEN_OPTS" Trying these 2 commands on the console, I found that the new MAVEN_OPTS value is ignored, the previous value is still here That is not the case if I write "export MAVEN_OPTS=..." I imagine this is the same problem with the CI server. Can the conf be changed? Can I have karma on it to try? I created a login: hboutemy. regards, Hervé Le mardi 25 mars 2008, Brian E. Fox a écrit : > Nope, nothing funky about the maven on there, the base 2.0 is the 2.0.8 > package. > > -----Original Message----- > From: Benjamin Bentmann [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 25, 2008 5:02 PM > To: Maven Developers List > Subject: Re: Maven and File Encoding > > > 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/tar > get/surefire-reports/TEST-org.apache.maven.its.Suite.xml > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
