On 26 April 2012 12:01, Anders Hammar <and...@hammar.net> wrote:

> The problem I have with using the mrm-maven-plugin is that it would
> then require the pom to be updated.
>
> Here's a scenario:
> In an environment with no direct access to central but an internal MRM
> is used, which is configured in settings.xml. I download some open
> source project that uses the m-invoker-plugin. I would very much like
> this Maven project to build including the its using m-invoker-plugin.
> But unless m-invoker-plugin uses my settings.xml, that would not work.
>

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.

So, in short, if you specify a custom settings.xml then no merge by default.


> 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
>
>

Reply via email to