Maven › Maven Wagon › Wagon - Dev

[VOTE] Apache Maven Invoker Plugin 1.6 (take 2)

Classic

List

Threaded

25 messages Options

olamy

[VOTE] Apache Maven Invoker Plugin 1.6 (take 2)

Hi,
I'd like to release Apache Maven Invoker plugin 1.6.
We fixed 14 issues ( release notes: http://s.apache.org/MINVOKER-1.6 )
Staging repository:
https://repository.apache.org/content/repositories/maven-097/
Staging site: http://maven.apache.org/plugins/maven-invoker-plugin-1.6/
(wait sync)

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

Thanks,
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Anders Hammar

Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 2)

+1 (non-binding)

/Anders

On Wed, Apr 25, 2012 at 10:53, Olivier Lamy <[hidden email]> wrote:

> Hi,
> I'd like to release Apache Maven Invoker plugin 1.6.
> We fixed 14 issues ( release notes: http://s.apache.org/MINVOKER-1.6 )
> Staging repository:
> https://repository.apache.org/content/repositories/maven-097/
> Staging site: http://maven.apache.org/plugins/maven-invoker-plugin-1.6/
> (wait sync)
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
> Thanks,
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Karl Heinz Marbaise-3

Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 2)

In reply to this post by olamy

Hi,

-1 (non binding) based on my reported problems...

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: [hidden email]
For additional commands, e-mail: [hidden email]

Karl Heinz Marbaise-3

Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 2)

In reply to this post by olamy

Hi,

i have a question concerning the parameters which given to instances of
the invoker-plugin on command during execution of the integration test:

Based on the files i've taken a look into it looks like there is a
profile activated or added on default so far as i understand this is
based on the new feature to inherit the information from the users
settings.xml ..
which means in other words any profile which is activated in my
settings.xml will automatically transferred to the called
maven-invoker...and of course will be used during the integration tests
and influence them instead of the given which i have configured.

Furthermore it seemed to be that the profile i've activated on command
line via:

mvn -Prun-its clean verify

is also put into the configuration for the calling
process...(invoker-settings....xml)...

So the questions: Is this documented anywhere (may be i oversight
it)...I have found the issue http://jira.codehaus.org/browse/MINVOKER-97
which is related to that....

I came across to that cause i looked into the build.log outputs and
found WARNINGS about profiles which couldn't be activated which hadn't
be the case with maven-invoker-plugin 1.5 ....
The following excerpt will show this (maven-invoker-plugin:1.6):

[INFO]
------------------------------------------------------------------------
[WARNING] The requested profile "maven-invoker" could not be activated
because it does not exist.
[WARNING] The requested profile "run-its" could not be activated because
it does not exist.
Running post-build script:
/Users/km/workspace/appassembler/appassembler-maven-plugin/target/it/assembleDirectoryTest/verify.groovy

The "maven-invoker" profiles is coming from my own .m2/settings.xml
file...where as the run-its is coming from command line...

The problem i see currently is that i defined to use a different
settings.xml file in my pom.xml configuration:

<settingsFile>src/it/settings.xml</settingsFile>

So why are these profiles been given or activated in contradiction to
the given settingsFile configuration...

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: [hidden email]
For additional commands, e-mail: [hidden email]

Karl Heinz Marbaise-3

Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 2)

In reply to this post by olamy

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

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: [hidden email]
For additional commands, e-mail: [hidden email]

stephenconnolly

Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 2)

The buildjob is used to store the results of the invoked runs.

That page describes the schema.

Iirc I was to write a Jenkins plugin to parse them so that you could track
the invoked tests in the trend graph... But I do get pulled every which way
and it can take a while before I return to these things.

On Wednesday, 25 April 2012, Karl Heinz Marbaise wrote:

> 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<http://maven.apache.org/plugins/maven-invoker-plugin-1.6/build-job.html>
>
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

olamy

Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 2)

In reply to this post by Karl Heinz Marbaise-3

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 <[hidden email]>:
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

stephenconnolly

Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 2)

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 <[hidden email]> 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 <[hidden email]>:
> > 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

olamy

Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 2)

So vote cancelled again :-).
I will make this merge optional (off by default).

2012/4/26 Stephen Connolly <[hidden email]>:

> 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 <[hidden email]> 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 <[hidden email]>:
>> > 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: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>>
>>
>>
>> --
>> Olivier Lamy
>> Talend: http://coders.talend.com
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

Anders Hammar

Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 2)

In reply to this post by stephenconnolly

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.
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.
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
<[hidden email]> wrote:

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

stephenconnolly

Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 2)

On 26 April 2012 12:01, Anders Hammar <[hidden email]> 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
> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
> >> > 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: [hidden email]
> >> > For additional commands, e-mail: [hidden email]
> >> >
> >>
> >>
> >>
> >> --
> >> Olivier Lamy
> >> Talend: http://coders.talend.com
> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

Anders Hammar

Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 2)

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

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

/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
>> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>> >> > 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: [hidden email]
>> >> > For additional commands, e-mail: [hidden email]
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Olivier Lamy
>> >> Talend: http://coders.talend.com
>> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [hidden email]
>> >> For additional commands, e-mail: [hidden email]
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

stephenconnolly

Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 2)

On 26 April 2012 13:40, Anders Hammar <[hidden email]> 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
> >> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
> >> >> > 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: [hidden email]
> >> >> > For additional commands, e-mail: [hidden email]
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Olivier Lamy
> >> >> Talend: http://coders.talend.com
> >> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: [hidden email]
> >> >> For additional commands, e-mail: [hidden email]
> >> >>
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

stephenconnolly

Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 2)

On 26 April 2012 13:57, Stephen Connolly <[hidden email]>wrote:

> On 26 April 2012 13:40, Anders Hammar <[hidden email]> 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.

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
>> >> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>> >> >> > 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: [hidden email]
>> >> >> > For additional commands, e-mail: [hidden email]
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Olivier Lamy
>> >> >> Talend: http://coders.talend.com
>> >> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: [hidden email]
>> >> >> For additional commands, e-mail: [hidden email]
>> >> >>
>> >> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [hidden email]
>> >> For additional commands, e-mail: [hidden email]
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>

olamy

Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 2)

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 <[hidden email]>:

> On 26 April 2012 13:57, Stephen Connolly <[hidden email]>wrote:
>
>> On 26 April 2012 13:40, Anders Hammar <[hidden email]> 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
>>> >> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>>> >> >> > 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: [hidden email]
>>> >> >> > For additional commands, e-mail: [hidden email]
>>> >> >> >
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> --
>>> >> >> Olivier Lamy
>>> >> >> Talend: http://coders.talend.com
>>> >> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>> >> >>
>>> >> >>
>>> ---------------------------------------------------------------------
>>> >> >> To unsubscribe, e-mail: [hidden email]
>>> >> >> For additional commands, e-mail: [hidden email]
>>> >> >>
>>> >> >>
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: [hidden email]
>>> >> For additional commands, e-mail: [hidden email]
>>> >>
>>> >>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>

Robert Scholte-3

Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 2)

In reply to this post by stephenconnolly

Op Thu, 26 Apr 2012 14:57:14 +0200 schreef Stephen Connolly
<[hidden email]>:

> On 26 April 2012 13:40, Anders Hammar <[hidden email]> 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
> ;-)
>

Well, I managed to get the ci-aggregator fixed last weekend, but the
versions-m-p still has some problems ;)
See http://bamboo.ci.codehaus.org/browse/MOJO

>
>>
>> > 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
>> >> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>> >> >> > 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: [hidden email]
>> >> >> > For additional commands, e-mail: [hidden email]
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Olivier Lamy
>> >> >> Talend: http://coders.talend.com
>> >> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: [hidden email]
>> >> >> For additional commands, e-mail: [hidden email]
>> >> >>
>> >> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [hidden email]
>> >> For additional commands, e-mail: [hidden email]
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

stephenconnolly

Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 2)

On 26 April 2012 23:13, Robert Scholte <[hidden email]> wrote:

> Op Thu, 26 Apr 2012 14:57:14 +0200 schreef Stephen Connolly <
> stephen.alan.connolly@gmail.**com <[hidden email]>>:
>
>
> On 26 April 2012 13:40, Anders Hammar <[hidden email]> 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
>> ;-)
>>
>>
> Well, I managed to get the ci-aggregator fixed last weekend, but the
> versions-m-p still has some problems ;)
> See http://bamboo.ci.codehaus.org/**browse/MOJO<http://bamboo.ci.codehaus.org/browse/MOJO>
>
>

IIRC that is some actual broken tests ;-)

>
>
>>
>>> > 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.connolly@gmail.**com <[hidden email]>>
>>> 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 <[hidden email]> 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 <[hidden email]>:
>>> >> >> > 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<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: [hidden email].**org<[hidden email]>
>>> >> >> > For additional commands, e-mail: [hidden email]
>>> >> >> >
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> --
>>> >> >> Olivier Lamy
>>> >> >> Talend: http://coders.talend.com
>>> >> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>> >> >>
>>> >> >> ------------------------------**------------------------------**
>>> ---------
>>> >> >> To unsubscribe, e-mail: [hidden email].**org<[hidden email]>
>>> >> >> For additional commands, e-mail: [hidden email]
>>> >> >>
>>> >> >>
>>> >>
>>> >> ------------------------------**------------------------------**
>>> ---------
>>> >> To unsubscribe, e-mail: [hidden email].**org<[hidden email]>
>>> >> For additional commands, e-mail: [hidden email]
>>> >>
>>> >>
>>>
>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: [hidden email].**org<[hidden email]>
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: [hidden email].**org<[hidden email]>
> For additional commands, e-mail: [hidden email]
>
>

stephenconnolly

Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 2)

On 26 April 2012 23:18, Stephen Connolly <[hidden email]>wrote:

>
>
> On 26 April 2012 23:13, Robert Scholte <[hidden email]> wrote:
>
>> Op Thu, 26 Apr 2012 14:57:14 +0200 schreef Stephen Connolly <
>> stephen.alan.connolly@gmail.**com <[hidden email]>>:
>>
>>
>> On 26 April 2012 13:40, Anders Hammar <[hidden email]> 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
>>> ;-)
>>>
>>>
>> Well, I managed to get the ci-aggregator fixed last weekend, but the
>> versions-m-p still has some problems ;)
>> See http://bamboo.ci.codehaus.org/**browse/MOJO<http://bamboo.ci.codehaus.org/browse/MOJO>
>>
>>
> IIRC that is some actual broken tests ;-)
>

Yep. it-resolve-ranges-001 is currently broken on trunk

>
>>
>>
>>>
>>>> > 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.connolly@gmail.**com <[hidden email]>>
>>>> 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 <[hidden email]> 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 <[hidden email]>:
>>>> >> >> > 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<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: [hidden email].**org<[hidden email]>
>>>> >> >> > For additional commands, e-mail: [hidden email]
>>>> >> >> >
>>>> >> >>
>>>> >> >>
>>>> >> >>
>>>> >> >> --
>>>> >> >> Olivier Lamy
>>>> >> >> Talend: http://coders.talend.com
>>>> >> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>> >> >>
>>>> >> >> ------------------------------**------------------------------**
>>>> ---------
>>>> >> >> To unsubscribe, e-mail: [hidden email].**org<[hidden email]>
>>>> >> >> For additional commands, e-mail: [hidden email]
>>>> >> >>
>>>> >> >>
>>>> >>
>>>> >> ------------------------------**------------------------------**
>>>> ---------
>>>> >> To unsubscribe, e-mail: [hidden email].**org<[hidden email]>
>>>> >> For additional commands, e-mail: [hidden email]
>>>> >>
>>>> >>
>>>>
>>>> ------------------------------**------------------------------**
>>>> ---------
>>>> To unsubscribe, e-mail: [hidden email].**org<[hidden email]>
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: [hidden email].**org<[hidden email]>
>> For additional commands, e-mail: [hidden email]
>>
>>
>

Anders Hammar

Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 2)

In reply to this post by olamy

Yes, I will. Will not happen until Wednesday though. (Holidays here in Sweden.)

Regarding the flag, inheriting setitngs.xml by default from the
invoking process if no settings.xml is specified in the flugin config
is not implemented? I'm asking based on mine and Stephen's discussion.

/Anders

On Thu, Apr 26, 2012 at 15:01, Olivier Lamy <[hidden email]> 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 <[hidden email]>:
>> On 26 April 2012 13:57, Stephen Connolly <[hidden email]>wrote:
>>
>>> On 26 April 2012 13:40, Anders Hammar <[hidden email]> 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
>>>> >> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>>>> >> >> > 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: [hidden email]
>>>> >> >> > For additional commands, e-mail: [hidden email]
>>>> >> >> >
>>>> >> >>
>>>> >> >>
>>>> >> >>
>>>> >> >> --
>>>> >> >> Olivier Lamy
>>>> >> >> Talend: http://coders.talend.com
>>>> >> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>> >> >>
>>>> >> >>
>>>> ---------------------------------------------------------------------
>>>> >> >> To unsubscribe, e-mail: [hidden email]
>>>> >> >> For additional commands, e-mail: [hidden email]
>>>> >> >>
>>>> >> >>
>>>> >>
>>>> >> ---------------------------------------------------------------------
>>>> >> To unsubscribe, e-mail: [hidden email]
>>>> >> For additional commands, e-mail: [hidden email]
>>>> >>
>>>> >>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

olamy

Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 2)

2012/4/29 Anders Hammar <[hidden email]>:
> Yes, I will. Will not happen until Wednesday though. (Holidays here in Sweden.)
>
> Regarding the flag, inheriting setitngs.xml by default from the
> invoking process if no settings.xml is specified in the flugin config
> is not implemented? I'm asking based on mine and Stephen's discussion.

If no settings specified, the maven invocation will use the default
one (~/.m2/settings.xml)

>
> /Anders
>
> On Thu, Apr 26, 2012 at 15:01, Olivier Lamy <[hidden email]> 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 <[hidden email]>:
>>> On 26 April 2012 13:57, Stephen Connolly <[hidden email]>wrote:
>>>
>>>> On 26 April 2012 13:40, Anders Hammar <[hidden email]> 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
>>>>> >> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>>>>> >> >> > 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: [hidden email]
>>>>> >> >> > For additional commands, e-mail: [hidden email]
>>>>> >> >> >
>>>>> >> >>
>>>>> >> >>
>>>>> >> >>
>>>>> >> >> --
>>>>> >> >> Olivier Lamy
>>>>> >> >> Talend: http://coders.talend.com
>>>>> >> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>> >> >>
>>>>> >> >>
>>>>> ---------------------------------------------------------------------
>>>>> >> >> To unsubscribe, e-mail: [hidden email]
>>>>> >> >> For additional commands, e-mail: [hidden email]
>>>>> >> >>
>>>>> >> >>
>>>>> >>
>>>>> >> ---------------------------------------------------------------------
>>>>> >> To unsubscribe, e-mail: [hidden email]
>>>>> >> For additional commands, e-mail: [hidden email]
>>>>> >>
>>>>> >>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>
>>
>>
>> --
>> Olivier Lamy
>> Talend: http://coders.talend.com
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>