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 ;-) > > > 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 > > /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 > >
