I just tried it, and it's the same issue.

Digging further into the code, it looks like the issue is here https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/SurefireProperties.java#L140-L159. User properties are set unconditionally after setting the configured system properties in <systemPropertyVariable>. Perhaps the user properties should be set first, and then any systemPropertyVariables?

I found SUREFIRE-491 about this also.

Guillaume

Le 26/02/2017 à 23:03, Tibor Digana a écrit :
Have you tried this?

<properties>
     <maven.repo.local>${project.build.directory}/it-repo</maven.repo.local>
</properties>

...
maven-failsafe-plugin:

   <systemPropertyVariables>
        <maven.repo.local>${maven.repo.local}</maven.repo.local>
   </systemPropertyVariables>

On Sun, Feb 26, 2017 at 10:01 PM, Guillaume Boué <gb...@apache.org> wrote:

Hi,

When a system property is passed on the CLI by the user, with
-Dprop=value, it seems that it is always preferred in the ITs of the
Failsafe Plugin, even when setting it to a different value in the
<systemPropertyVariables> configuration. I think this is due to
SUREFIRE-121, but is there a good way around that? I would like the system
property defined in <systemPropertyVariables> to override the one defined
on the CLI during IT execution.

As an example, consider the build of the maven-remote-resources-plugin.
When trying to run the ITs with a custom local repo set on the CLI (with
-Dmaven.repo.local=...), they all fail because they can't resolve the
plugin in the version being built. What happens is that, even though there
is

   <systemPropertyVariables>
     <!-- Pass this through to the tests (if set!) to have them pick the
right repository -->
<maven.repo.local>${project.build.directory}/it-repo</maven.repo.local>
    </systemPropertyVariables>

in the POM, to force the local repository to point to a location where the
plugin was installed before-hand, it is getting ignored because
-Dmaven.repo.local was also set on the CLI (and to a location where the
plugin is rightly not installed). The current workaround I have is to set a
different system property, like <localRepositoryPath>, and then use

verifier.setLocalRepo( System.getProperty( "localRepositoryPath" ) );

in each IT code. But this sounds very brittle since the same issue could
happen again if someone were to define -DlocalRepositoryPath for any reason
on the CLI...

Guillaume


---
L'absence de virus dans ce courrier électronique a été vérifiée par le
logiciel antivirus Avast.
https://www.avast.com/antivirus


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org






---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus

Reply via email to