maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Hay (JIRA)" <>
Subject [jira] Commented: (SUREFIRE-308) Setting environment variables in surefire configuration overwrite the existing environment
Date Fri, 30 May 2008 06:01:22 GMT


Tim Hay commented on SUREFIRE-308:

Even though this is closed, it's I think it's still worth commenting on, considering the extreme
difficulty I had finding out what the problem was in the first place, given the errors I was
experiencing (see stacktrace below)
Dan's comment above is correct. In a Windows XP environment, I found that when an <environmentVariables>
element was added to the configuration for version 2.3 of the surefire plugin, all other environment
variables were from then on unavailable. In particular, the SYSTEM_ROOT variable, required
when using apache CXF. In this situation, we would get the following stacktrace:
30/05/2008 15:49:37 org.apache.cxf.phase.PhaseInterceptorChain doIntercept
INFO: Interceptor has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: Unrecognized Windows Sockets error: 10106: create
        at org.apache.cxf.interceptor.AbstractOutDatabindingInterceptor.writeParts(
        at org.apache.cxf.interceptor.BareOutInterceptor.handleMessage(
        at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(
        at org.apache.cxf.endpoint.ClientImpl.invoke(
        at org.apache.cxf.endpoint.ClientImpl.invoke(
        at org.apache.cxf.frontend.ClientProxy.invokeSync(
        at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(
        at $Proxy56.getUsernameList(Unknown Source)
        at com.suncorp.jpetstore.api.service.account.AccountServiceSoapJmsIntegrationTest.shouldProxyGetUsernameList(

There are two ways to work around this:
1) Override the dependency surefire has on plexus-utils, such that it explicitly depends on
version 1.4.3.
2) Update to the latest version of the Surefire Plugin - which at time of writing is 2.4.3.

Obviously, option 2 is preferred.

The following details relevant environment information:
Windows XP 5.1
Java: jdk 1.6.0_06
Maven v2.0.7 (and then upgraded to v2.0.9)

> Setting environment variables in surefire configuration overwrite the existing environment
> ------------------------------------------------------------------------------------------
>                 Key: SUREFIRE-308
>                 URL:
>             Project: Maven Surefire
>          Issue Type: Bug
>          Components: plugin
>    Affects Versions: 2.0 (2.2 plugin), 2.3
>         Environment: Linux
>            Reporter: Renaud Julienne
> It's possible to set additional environment properties in surefire plugin configuration
>             <plugin>
>               <artifactId>maven-surefire-plugin</artifactId>
>               <configuration>
>                 <environmentVariables>
>                   <NAME>value</NAME>
>                 </environmentVariables>
>               </configuration>
>             </plugin>
> As described in plugin documentation, this should ADD the environment variable NAME to
the existing environment when forking to launch the tests.
> What happens in fact is that it completely OVERWRITE the existing environment as soon
as you use this configuration property : no more $HOME, no more $PATH, etc... Whereas when
this property is not set, the existing environment ($HOME, $PATH, ...) remains present.
> This is not critical as there is a workaround to still have $HOME or $PATH for example
by setting:
>             <plugin>
>               <artifactId>maven-surefire-plugin</artifactId>
>               <configuration>
>                 <environmentVariables>
>                   <NAME>value</NAME>
>                   <HOME>${env.HOME}</HOME>
>                   <PATH>${env.PATH}</PATH>
>                 </environmentVariables>
>               </configuration>
>             </plugin>
> but afaic, this remains a high issue.
> I did not have time to investigate much, but it seems the problem comes from org.codehaus.plexus.util.cli.CommandLine,
so this bug may be also opened there.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


View raw message