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. /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
