2012/4/29 Anders Hammar <and...@hammar.net>: > Yes, I will. Will not happen until Wednesday though. (Holidays here in > Sweden.) > > Regarding the flag, inheriting setitngs.xml by default from the > invoking process if no settings.xml is specified in the flugin config > is not implemented? I'm asking based on mine and Stephen's discussion.
If no settings specified, the maven invocation will use the default one (~/.m2/settings.xml) > > /Anders > > On Thu, Apr 26, 2012 at 15:01, Olivier Lamy <ol...@apache.org> wrote: >> ok in order to try make all happy :-) I will make that configurable. >> @Anders I have pushed a snapshot with a new flag called >> mergeUserSettings. Can you try with your use case ? >> >> 2012/4/26 Stephen Connolly <stephen.alan.conno...@gmail.com>: >>> On 26 April 2012 13:57, Stephen Connolly >>> <stephen.alan.conno...@gmail.com>wrote: >>> >>>> On 26 April 2012 13:40, Anders Hammar <and...@hammar.net> wrote: >>>> >>>>> > I would argue that those are broken projects. You should pretty much >>>>> always >>>>> > use mrm if you are using invoker for testing a maven plugin. There are >>>>> > cases where you might use invoker for something else, in which case you >>>>> > should not be specifying a custom settings.xml. >>>>> >>>>> I might be wrong, but this would be the case for most of the plugins >>>>> at Apache Maven then. And all mojos at Codehaus Mojo. >>>>> >>>> >>>> Correct. Everyone except versions-maven-plugin @ mojo is doing it wrong ;-) >>>> >>> >>> Some are using the old hack to refer to the default local repo from the >>> invoking process, but with Maven 3 the assumptions that makes can be >>> invalidated with IDE integrations. >>> >>> >>>> >>>>> >>>>> > So, in short, if you specify a custom settings.xml then no merge by >>>>> default. >>>>> >>>>> Ah, so could the rule be that if no settings.xml is specified use the >>>>> one of the calling process. If one is specified, do not merge by >>>>> default? >>>>> >>>> >>>> That would be the correct thing to do IMHO >>>> >>> >>> Of course in that case you need to ensure that you use the same tricks that >>> m-release-p uses to get the settings from the session as the assumption >>> that settings.xml is even a file on disk is no longer valid in Maven 3 (not >>> that I have seen anyone not store their settings in a settings.xml file, >>> more that Maven 3 Embedder allows for the settings to be provided by a >>> non-file mechanism >>> >>> >>>> >>>> >>>>> >>>>> /Anders >>>>> >>>>> > >>>>> > >>>>> >> That's why I want the calling process' settings-xml to be merged. And >>>>> >> I argue that, at least in my use case :-), that would be the default >>>>> >> behavior. >>>>> >> >>>>> > >>>>> > I have no issue with being able to turn it on via the CLI if you know >>>>> what >>>>> > you are doing, but where a project has provided a custom settings.xml it >>>>> > must be assumed that the reason for the custom settings.xml is because >>>>> they >>>>> > want to control the invoker environment completely... if they are not >>>>> using >>>>> > mrm then they are being foolish as there is no other way to lock down >>>>> the >>>>> > invoker environment *and* work transparently behind a proxy at the >>>>> present >>>>> > time. >>>>> > >>>>> > If this is not the default behavior but needs to be configured, it has >>>>> >> to be able to turn on from command line as one shouldn't have to >>>>> >> update the pom IMO. >>>>> >> >>>>> >> At least my couple of cents, >>>>> >> /Anders >>>>> >> On Thu, Apr 26, 2012 at 10:15, Stephen Connolly >>>>> >> <stephen.alan.conno...@gmail.com> wrote: >>>>> >> > I actually think the merge feature is a step backwards and I am >>>>> toying >>>>> >> with >>>>> >> > being -1 on the commit. >>>>> >> > >>>>> >> > for proxies I think mrm-maven-plugin @ mojo is the way to go. >>>>> >> > >>>>> >> > invoker is a different use case from release, so passing through the >>>>> >> > settings is, in general, a bad thing. If you make the merge an opt-in >>>>> >> then >>>>> >> > that is OK, but personally I cannot see any good use case for it now >>>>> that >>>>> >> > we have mrm-maven-plugin to solve the proxy issue >>>>> >> > >>>>> >> > On 26 April 2012 09:07, Olivier Lamy <ol...@apache.org> wrote: >>>>> >> > >>>>> >> >> Good catch on the warning for activated profiles. >>>>> >> >> They are activated in the maven build so the invoker plugin merge >>>>> >> >> those setting with those eventually defined in the mojo >>>>> configuration >>>>> >> >> field (<settingsFile> ). >>>>> >> >> What I can do is made this merge feature optional (off by default >>>>> and >>>>> >> >> add a debug flag to display it for debugging purpose). >>>>> >> >> WDYT ? >>>>> >> >> >>>>> >> >> 2012/4/25 Karl Heinz Marbaise <khmarba...@gmx.de>: >>>>> >> >> > Hi, >>>>> >> >> > >>>>> >> >> > just an other question came to my mind >>>>> >> >> > >>>>> >> >> > What is the purpose of the >>>>> >> >> > >>>>> >> >>>>> http://maven.apache.org/plugins/maven-invoker-plugin-1.6/build-job.html >>>>> >> >> This is the format of the file produced by invoker plugin and used >>>>> by >>>>> >> >> the report mojo. >>>>> >> >> > >>>>> >> >> > It's given as a link in the docs? But i can't find an explanation >>>>> >> which >>>>> >> >> > intention it has ? May be i oversight it simply ? >>>>> >> >> > >>>>> >> >> > Can someone enlighten me? >>>>> >> >> > >>>>> >> >> > Thanks in advance... >>>>> >> >> > >>>>> >> >> > >>>>> >> >> > Kind regards >>>>> >> >> > Karl Heinz Marbaise >>>>> >> >> > -- >>>>> >> >> > SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / >>>>> 415 893 >>>>> >> >> > Dipl.Ing.(FH) Karl Heinz Marbaise ICQ#: 135949029 >>>>> >> >> > Hauptstrasse 177 USt.IdNr: DE191347579 >>>>> >> >> > 52146 Würselen http://www.soebes.de >>>>> >> >> > >>>>> >> >> > >>>>> --------------------------------------------------------------------- >>>>> >> >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>> >> >> > For additional commands, e-mail: dev-h...@maven.apache.org >>>>> >> >> > >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> -- >>>>> >> >> Olivier Lamy >>>>> >> >> Talend: http://coders.talend.com >>>>> >> >> http://twitter.com/olamy | http://linkedin.com/in/olamy >>>>> >> >> >>>>> >> >> >>>>> --------------------------------------------------------------------- >>>>> >> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>> >> >> For additional commands, e-mail: dev-h...@maven.apache.org >>>>> >> >> >>>>> >> >> >>>>> >> >>>>> >> --------------------------------------------------------------------- >>>>> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>> >> For additional commands, e-mail: dev-h...@maven.apache.org >>>>> >> >>>>> >> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>> >>>>> >>>> >> >> >> >> -- >> Olivier Lamy >> Talend: http://coders.talend.com >> http://twitter.com/olamy | http://linkedin.com/in/olamy >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
