Hi, AFAIK no rush :-) So take the time to test your various use cases. 2012/5/2 Anders Hammar <[email protected]>: >> 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 <[email protected]> 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 <[email protected]>: >>>>> On 26 April 2012 13:57, Stephen Connolly >>>>> <[email protected]>wrote: >>>>> >>>>>> On 26 April 2012 13:40, Anders Hammar <[email protected]> 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 >>>>>>> >> <[email protected]> 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 <[email protected]> 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 <[email protected]>: >>>>>>> >> >> > 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: [email protected] >>>>>>> >> >> > For additional commands, e-mail: [email protected] >>>>>>> >> >> > >>>>>>> >> >> >>>>>>> >> >> >>>>>>> >> >> >>>>>>> >> >> -- >>>>>>> >> >> Olivier Lamy >>>>>>> >> >> Talend: http://coders.talend.com >>>>>>> >> >> http://twitter.com/olamy | http://linkedin.com/in/olamy >>>>>>> >> >> >>>>>>> >> >> >>>>>>> --------------------------------------------------------------------- >>>>>>> >> >> To unsubscribe, e-mail: [email protected] >>>>>>> >> >> For additional commands, e-mail: [email protected] >>>>>>> >> >> >>>>>>> >> >> >>>>>>> >> >>>>>>> >> --------------------------------------------------------------------- >>>>>>> >> To unsubscribe, e-mail: [email protected] >>>>>>> >> For additional commands, e-mail: [email protected] >>>>>>> >> >>>>>>> >> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>> For additional commands, e-mail: [email protected] >>>>>>> >>>>>>> >>>>>> >>>> >>>> >>>> >>>> -- >>>> Olivier Lamy >>>> Talend: http://coders.talend.com >>>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> >> >> -- >> Olivier Lamy >> Talend: http://coders.talend.com >> http://twitter.com/olamy | http://linkedin.com/in/olamy >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
-- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
