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.htmlhttp://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 SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 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
Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 2)
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
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 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 SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 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
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 stephen.alan.conno...@gmail.com: 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 -- 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
Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 2)
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 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
Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 2)
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 SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 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
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 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
Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 2)
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 SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 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
Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 2)
On 26 April 2012 13:57, Stephen Connolly stephen.alan.conno...@gmail.comwrote: 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 ;-) 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.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 SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 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:
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 stephen.alan.conno...@gmail.com: On 26 April 2012 13:57, Stephen Connolly stephen.alan.conno...@gmail.comwrote: 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 ;-) 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.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
[VOTE] Release Apache Maven SCM 1.7
Hi, I'd like to release Apache Maven SCM 1.7. We fixed 18 issues ( http://s.apache.org/SCM-1.7 ) One new feature is the support of Jazz Scm (thanks to Chris Graham !) The staging repository is available here: https://repository.apache.org/content/repositories/maven-112/ The staging site: http://maven.apache.org/scm-1.7/ (the full content is not yet sync). [+1] [0] [-1] Vote open for 72H. Thanks -- 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
Re: [VOTE] Release Maven Site Plugin version 2.4
+1 from me On 2012-04-23 22:30, Dennis Lundberg wrote: Hi, We solved 9 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146styleName=Htmlversion=17454 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11146status=1 Staging repo: https://repository.apache.org/content/repositories/maven-086/ Staging site: http://maven.apache.org/plugins/maven-site-plugin-2.4/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[RESULT] [VOTE] Release Maven Site Plugin version 2.4
Hi, The vote has passed with the following result : +1 (binding): Hervé Boutemy, Olivier Lamy, Vincent Siveton, Dennis Lundberg +1 (non binding): Lukas Theussl I will promote the artifacts to the central repo. Thanks to all voters! On 2012-04-23 22:30, Dennis Lundberg wrote: Hi, We solved 9 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146styleName=Htmlversion=17454 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11146status=1 Staging repo: https://repository.apache.org/content/repositories/maven-086/ Staging site: http://maven.apache.org/plugins/maven-site-plugin-2.4/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 2)
Op Thu, 26 Apr 2012 14:57:14 +0200 schreef Stephen Connolly stephen.alan.conno...@gmail.com: 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 ;-) 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 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 SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 2)
On 26 April 2012 23:13, Robert Scholte apa...@sourcegrounds.com wrote: Op Thu, 26 Apr 2012 14:57:14 +0200 schreef Stephen Connolly stephen.alan.connolly@gmail.**com stephen.alan.conno...@gmail.com: 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 ;-) 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/MOJOhttp://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 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.htmlhttp://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 SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 135949029 Hauptstrasse 177 USt.IdNr: DE191347579 52146 Würselen http://www.soebes.de --**--** - To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-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-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org --**--** - To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 2)
On 26 April 2012 23:18, Stephen Connolly stephen.alan.conno...@gmail.comwrote: On 26 April 2012 23:13, Robert Scholte apa...@sourcegrounds.com wrote: Op Thu, 26 Apr 2012 14:57:14 +0200 schreef Stephen Connolly stephen.alan.connolly@gmail.**com stephen.alan.conno...@gmail.com: 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 ;-) 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/MOJOhttp://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 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.htmlhttp://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 SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 135949029 Hauptstrasse 177 USt.IdNr: DE191347579 52146 Würselen http://www.soebes.de --**--** - To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-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-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org --**--** - To unsubscribe, e-mail:
[jira] Subscription: Design Best Practices
Issue Subscription
Filter: Design Best Practices (25 issues)
Subscriber: mavendevlist
Key Summary
MNG-2184Possible problem with @aggregator and forked lifecycles
https://jira.codehaus.org/browse/MNG-2184
MNG-612 implement conflict resolution techniques
https://jira.codehaus.org/browse/MNG-612
MNG-1563how to write integration tests
https://jira.codehaus.org/browse/MNG-1563
MNG-474 performance improvement for forked lifecycles
https://jira.codehaus.org/browse/MNG-474
MNG-4656Declarative plugins similar to jsp tags or jsf composites
https://jira.codehaus.org/browse/MNG-4656
MNG-139 server definitions should be reusable - review use of repository IDs
https://jira.codehaus.org/browse/MNG-139
MNG-1381best practices: testing strategies
https://jira.codehaus.org/browse/MNG-1381
MNG-1950Ability to introduce new lifecycles phases
https://jira.codehaus.org/browse/MNG-1950
MNG-2125[doc] when and how to define plugins in a pom
https://jira.codehaus.org/browse/MNG-2125
MNG-2381improved control over the repositories in the POM
https://jira.codehaus.org/browse/MNG-2381
MNG-4713${basedir} variable makes portable builds overly difficult
https://jira.codehaus.org/browse/MNG-4713
MNG-5277best practices: The Maven Way
https://jira.codehaus.org/browse/MNG-5277
MNG-367 best practices: multi-user installation
https://jira.codehaus.org/browse/MNG-367
MNG-41 best practices: site management
https://jira.codehaus.org/browse/MNG-41
MNG-868 Use uniform format for properties and other tags
https://jira.codehaus.org/browse/MNG-868
MNG-1463best practices: plugin inheritance for a multi project build
https://jira.codehaus.org/browse/MNG-1463
MNG-125 guarded mojo execution
https://jira.codehaus.org/browse/MNG-125
MNG-416 best practices: multiple profile deployments
https://jira.codehaus.org/browse/MNG-416
MNG-657 possible chicken and egg problem with extensions
https://jira.codehaus.org/browse/MNG-657
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-1569Make build process info read-only to mojos, and provide mechanism
for explicit out-params for mojos to declare
https://jira.codehaus.org/browse/MNG-1569
MNG-1867deprecate system scope, analyse other use cases
https://jira.codehaus.org/browse/MNG-1867
MNG-1423best practices: setting up multi-module build
https://jira.codehaus.org/browse/MNG-1423
MNG-1468best practices: version management in multi project builds
https://jira.codehaus.org/browse/MNG-1468
MNG-1425best practices: the location of configuration files vs resources
https://jira.codehaus.org/browse/MNG-1425
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
