maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anders Hammar <and...@hammar.net>
Subject Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 2)
Date Wed, 02 May 2012 12:00:41 GMT
> 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 <olamy@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.connolly@gmail.com>:
>>>> On 26 April 2012 13:57, Stephen Connolly <stephen.alan.connolly@gmail.com>wrote:
>>>>
>>>>> On 26 April 2012 13:40, Anders Hammar <anders@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.connolly@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 <olamy@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 <khmarbaise@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-unsubscribe@maven.apache.org
>>>>>> >> >> > For additional commands, e-mail: dev-help@maven.apache.org
>>>>>> >> >> >
>>>>>> >> >>
>>>>>> >> >>
>>>>>> >> >>
>>>>>> >> >> --
>>>>>> >> >> Olivier Lamy
>>>>>> >> >> Talend: http://coders.talend.com
>>>>>> >> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>> >> >>
>>>>>> >> >>
>>>>>> ---------------------------------------------------------------------
>>>>>> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> >> >> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>> >> >>
>>>>>> >> >>
>>>>>> >>
>>>>>> >> ---------------------------------------------------------------------
>>>>>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> >> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>> >>
>>>>>> >>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>>
>>> --
>>> Olivier Lamy
>>> Talend: http://coders.talend.com
>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message