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/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]
>
>
--
Cheers, Stuart
