> If no settings specified, the maven invocation will use the default > one (~/.m2/settings.xml)
Actually it will use the settings of the calling process, which could be something different than the default file-based one. Due to corporate infrastructure reasons I couldn't test one of my actual use case project, but based on a similar laptop setup I verify that the inheriting feature works as I want it to work. But I guess the IT in the plugin shows that as well. > >> >> /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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
