It's not that easy. The corporate infrastructure only proxies central, not any snapshot repos. So I can't test a Snapshot version.
So what I've done is verifying that the plugin now works with the new embedded Maven 3 feature of Hudson. Really my main goal and should be what I need for the corporate use case as well. I also "verified" the code and everything seems ok. On Wed, May 2, 2012 at 2:08 PM, Olivier Lamy <ol...@apache.org> wrote: > Hi, > AFAIK no rush :-) > So take the time to test your various use cases. > > 2012/5/2 Anders Hammar <and...@hammar.net>: >>> 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 >> > > > > -- > 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
