On 21 February 2017 at 09:35, Tibor Digana <tibordig...@apache.org> wrote:
> Stephen, so you avoided the duplicates. > I have questions. > > Is it really necessary to keep duplicates of system properties in > *List<String>** args*? > Is it necessary to pass ordered duplicates to CLI Manager and to rely on > CLI Manager to take care of removing duplicates? > *CommandLine config = cliManager.parse( args.toArray( new > String[args.size()] ) );* > It looks like distributed functionality over two classes. > Is it better to find the previous system property and replace it in the way > as I did in Surefire? > > Well it is long established behaviour in maven that the last defined property value for a key wins. If we had the same behaviour for all the CLI options then we would have a simpler behaviour entirely, because we could just append the CLI args onto the end of the list. I could have investigated making that fix, but it seemed wiser to go for the pragmatic option of handling the merge in a package local class (and we needed a custom class to access the protected constructor, etc) Changing integration tests in Surefire to make surefire build on Maven due to changes in Maven is something that you should only do if you understand why. Otherwise you run the risk of introducing regressions. > > > > On Tue, Feb 21, 2017 at 1:17 AM, stephenconnolly [via Maven] < > ml-node+s40175n5899412...@n5.nabble.com> wrote: > > > After some digging I think the fix for MNG-6078 is incorrect. I have > taken > > an initial stab at what I believe to be a more correct approach: > > https://github.com/apache/maven/tree/mng-6078-take-2 > > > > If the integration tests pass: > > https://builds.apache.org/job/maven-3.x-jenkinsfile/job/mng-6078-take-2/ > > then I believe that should solve the regressions in the surefire build > > between Maven 3.3.9 and Maven 3.5.0-SNAPSHOT > > > > While there are other issues with Surefire, at this point in time, from > > the > > PoV of a core release, what we need is that the build behaves the same > for > > 3.3.9 and 3.5.0-SNAPSHOT > > > > Let's see what the build result is tomorrow! > > > > On 18 February 2017 at 17:48, Christian Schulte <[hidden email] > > <http:///user/SendEmail.jtp?type=node&node=5899412&i=0>> wrote: > > > > > Am 02/18/17 um 11:41 schrieb Stephen Connolly: > > > > We need help testing on Solaris 10/11 if anyone has access to such a > > > system > > > > > > On a SPARC machine, if possible, please. > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [hidden email] > > <http:///user/SendEmail.jtp?type=node&node=5899412&i=1> > > > For additional commands, e-mail: [hidden email] > > <http:///user/SendEmail.jtp?type=node&node=5899412&i=2> > > > > > > > > > > > > ------------------------------ > > If you reply to this email, your message will be added to the discussion > > below: > > http://maven.40175.n5.nabble.com/I-think-we-are-ready-for-3-5-0-alpha-1- > > tp5897626p5899412.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=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3 > wxNDIxNjZ8LTI4OTQ5MjEwMg==> > > . > > 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/I-think-we-are-ready-for-3-5-0-alpha-1-tp5897626p5899447.html > Sent from the Maven Developers mailing list archive at Nabble.com. >
