>>Perhaps the user properties should be set first, and then any
systemPropertyVariables?
I don't think so. User's properties should be finally preferable however I
understand that you do not want to have so hard restriction.
The solution would be the idiom I mentioned before where
systemPropertyVariable refers to Maven property which refers to user's
system property - all with same key name. Not following the idiom would
break the restriction and property in <configuration> remains unchanged.
But this is not so easy because this may break the current user's and our
internal integration tests.
As a solution would be to introduce a config parameter to alter this
behavior in Surefire 3.0.
Our internal system property key "localRepository" set initially in forked
jvm refers to Maven Local Repo.
I think you cannot override it, see AbstractSurefireMojo.java L984, however
it is different property key.
Do you definitely want to use "maven.repo.local"?
It looks to me that Arquillian uses "localRepository".
<systemPropertyVariables>
<localRepository>your m2 local repository</localRepository>
</systemPropertyVariables>
On Sun, Feb 26, 2017 at 11:29 PM, Guillaume Boué-2 [via Maven] <
[email protected]> wrote:
> 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é <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5900380&i=0>> 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: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5900380&i=1>
> >> For additional commands, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5900380&i=2>
> >>
> >>
> >
>
>
>
> ---
> L'absence de virus dans ce courrier électronique a été vérifiée par le
> logiciel antivirus Avast.
> https://www.avast.com/antivirus
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/Passing-a-system-property-
> already-defined-on-CLI-to-Failsafe-Plugin-tp5900361p5900380.html
> To start a new topic under Maven Developers, email
> [email protected]
> To unsubscribe from Maven Developers, click here
> <http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=142166&code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==>
> .
> NAML
> <http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
View this message in context:
http://maven.40175.n5.nabble.com/Passing-a-system-property-already-defined-on-CLI-to-Failsafe-Plugin-tp5900361p5900382.html
Sent from the Maven Developers mailing list archive at Nabble.com.
