"maven.repo.local" is used automatically by maven-verifier to set-up the
local repository (see
https://github.com/apache/maven-shared/blob/trunk/maven-verifier/src/main/java/org/apache/maven/it/Verifier.java#L1732),
so it would have been nice to refer directly to it in the
systemPropertyVariables... But otherwise, yes, setting another system
property does the job, until someone decides to set that one also on the
CLI, which would break the test again...
With regard to the user properties, since <systemPropertyVariables> is
"closer" to the IT than the user properties, I'd expect those to win
conflicts. However, if it is really intended not to do it, I'll see
about adding a note in the doc
http://maven.apache.org/components/surefire/maven-failsafe-plugin/examples/system-properties.html.
It doesn't mention this use-case.
Thanks,
Guillaume
Le 26/02/2017 à 23:56, Tibor Digana a écrit :
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] <
ml-node+s40175n5900380...@n5.nabble.com> 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
ml-node+s40175n142166...@n5.nabble.com
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.
---
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
