that's it thanks for the precise explanations Le samedi 29 mars 2008, Stuart McCulloch a écrit : > On 29/03/2008, Hervé BOUTEMY <[EMAIL PROTECTED]> wrote: > > 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=..." > > FYI, using "set MAVEN_OPTS=..." won't actually set the variable on > linux/unix > because the builtin "set" command is actually used to configure shell > options, > not update environment variables (not to be confused with set on Windows!) > > in fact "set MAVEN_OPTS=..." actually sets $1 to be "MAVEN_OPTS=..." :) > > also the "export MAVEN_OPTS=..." syntax doesn't work on all linux/unix > shells, > most notably ksh, so the best way to set and export an environment variable > is: > > MAVEN_OPTS=... > export MAVEN_OPTS > > HTH > > 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/ta > > >r 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
