You can think of PR in github and alter the behavior on configuration level. Maybe we should think of extension in the configuration parameter performed in the same way used in maven-shade-plugin: implementation=my/Class. This implementation would compute effective system properties, merge them, resolve placeholders, etc. Default implementation should be embedded with one field yet which would determine order of properties to be merged.
On Mon, Feb 27, 2017 at 12:24 AM, Guillaume Boué <[email protected]> wrote: > "maven.repo.local" is used automatically by maven-verifier to set-up the > local repository (see https://github.com/apache/mave > n-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/compon > ents/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] < >> [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?m >>> acro=unsubscribe_by_code&node=142166&code=dGlib3JkaWdhbmFAYX >>> BhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==> >>> . >>> NAML >>> <http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?m >>> acro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base >>> =nabble.naml.namespaces.BasicNamespace-nabble.view.web. >>> template.NabbleNamespace-nabble.view.web.template.NodeNamesp >>> ace&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.c >> om/Passing-a-system-property-already-defined-on-CLI-to-Fails >> afe-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: [email protected] > For additional commands, e-mail: [email protected] > > -- Cheers Tibor
