Thanks for the polished ping :-) I will take care of that this week. 2012/5/21 Anders Hammar <and...@hammar.net>: > 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 >
-- 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
