I'd appreciate spinning a release of this. When staged I can test on my real corporate use cases. Should be very similar to my test on the snapshot though, so I don't expect any issues.
/Anders On Wed, May 2, 2012 at 2:17 PM, Anders Hammar <and...@hammar.net> wrote: > 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
