Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 2)
I'd appreciate spinning a release of this. When staged I can test on my real corporate use cases. Should be very similar to my test on the snapshot though, so I don't expect any issues. /Anders On Wed, May 2, 2012 at 2:17 PM, Anders Hammar and...@hammar.net wrote: It's not that easy. The corporate infrastructure only proxies central, not any snapshot repos. So I can't test a Snapshot version. So what I've done is verifying that the plugin now works with the new embedded Maven 3 feature of Hudson. Really my main goal and should be what I need for the corporate use case as well. I also verified the code and everything seems ok. On Wed, May 2, 2012 at 2:08 PM, Olivier Lamy ol...@apache.org wrote: Hi, AFAIK no rush :-) So take the time to test your various use cases. 2012/5/2 Anders Hammar and...@hammar.net: If no settings specified, the maven invocation will use the default one (~/.m2/settings.xml) Actually it will use the settings of the calling process, which could be something different than the default file-based one. Due to corporate infrastructure reasons I couldn't test one of my actual use case project, but based on a similar laptop setup I verify that the inheriting feature works as I want it to work. But I guess the IT in the plugin shows that as well. /Anders On Thu, Apr 26, 2012 at 15:01, Olivier Lamy ol...@apache.org wrote: ok in order to try make all happy :-) I will make that configurable. @Anders I have pushed a snapshot with a new flag called mergeUserSettings. Can you try with your use case ? 2012/4/26 Stephen Connolly stephen.alan.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
Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 2)
Thanks for the polished ping :-) I will take care of that this week. 2012/5/21 Anders Hammar and...@hammar.net: I'd appreciate spinning a release of this. When staged I can test on my real corporate use cases. Should be very similar to my test on the snapshot though, so I don't expect any issues. /Anders On Wed, May 2, 2012 at 2:17 PM, Anders Hammar and...@hammar.net wrote: It's not that easy. The corporate infrastructure only proxies central, not any snapshot repos. So I can't test a Snapshot version. So what I've done is verifying that the plugin now works with the new embedded Maven 3 feature of Hudson. Really my main goal and should be what I need for the corporate use case as well. I also verified the code and everything seems ok. On Wed, May 2, 2012 at 2:08 PM, Olivier Lamy ol...@apache.org wrote: Hi, AFAIK no rush :-) So take the time to test your various use cases. 2012/5/2 Anders Hammar and...@hammar.net: If no settings specified, the maven invocation will use the default one (~/.m2/settings.xml) Actually it will use the settings of the calling process, which could be something different than the default file-based one. Due to corporate infrastructure reasons I couldn't test one of my actual use case project, but based on a similar laptop setup I verify that the inheriting feature works as I want it to work. But I guess the IT in the plugin shows that as well. /Anders On Thu, Apr 26, 2012 at 15:01, Olivier Lamy ol...@apache.org wrote: ok in order to try make all happy :-) I will make that configurable. @Anders I have pushed a snapshot with a new flag called mergeUserSettings. Can you try with your use case ? 2012/4/26 Stephen Connolly stephen.alan.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 ).
Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 2)
If no settings specified, the maven invocation will use the default one (~/.m2/settings.xml) Actually it will use the settings of the calling process, which could be something different than the default file-based one. Due to corporate infrastructure reasons I couldn't test one of my actual use case project, but based on a similar laptop setup I verify that the inheriting feature works as I want it to work. But I guess the IT in the plugin shows that as well. /Anders On Thu, Apr 26, 2012 at 15:01, Olivier Lamy ol...@apache.org wrote: ok in order to try make all happy :-) I will make that configurable. @Anders I have pushed a snapshot with a new flag called mergeUserSettings. Can you try with your use case ? 2012/4/26 Stephen Connolly stephen.alan.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
Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 2)
Hi, AFAIK no rush :-) So take the time to test your various use cases. 2012/5/2 Anders Hammar and...@hammar.net: If no settings specified, the maven invocation will use the default one (~/.m2/settings.xml) Actually it will use the settings of the calling process, which could be something different than the default file-based one. Due to corporate infrastructure reasons I couldn't test one of my actual use case project, but based on a similar laptop setup I verify that the inheriting feature works as I want it to work. But I guess the IT in the plugin shows that as well. /Anders On Thu, Apr 26, 2012 at 15:01, Olivier Lamy ol...@apache.org wrote: ok in order to try make all happy :-) I will make that configurable. @Anders I have pushed a snapshot with a new flag called mergeUserSettings. Can you try with your use case ? 2012/4/26 Stephen Connolly stephen.alan.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
Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 2)
It's not that easy. The corporate infrastructure only proxies central, not any snapshot repos. So I can't test a Snapshot version. So what I've done is verifying that the plugin now works with the new embedded Maven 3 feature of Hudson. Really my main goal and should be what I need for the corporate use case as well. I also verified the code and everything seems ok. On Wed, May 2, 2012 at 2:08 PM, Olivier Lamy ol...@apache.org wrote: Hi, AFAIK no rush :-) So take the time to test your various use cases. 2012/5/2 Anders Hammar and...@hammar.net: If no settings specified, the maven invocation will use the default one (~/.m2/settings.xml) Actually it will use the settings of the calling process, which could be something different than the default file-based one. Due to corporate infrastructure reasons I couldn't test one of my actual use case project, but based on a similar laptop setup I verify that the inheriting feature works as I want it to work. But I guess the IT in the plugin shows that as well. /Anders On Thu, Apr 26, 2012 at 15:01, Olivier Lamy ol...@apache.org wrote: ok in order to try make all happy :-) I will make that configurable. @Anders I have pushed a snapshot with a new flag called mergeUserSettings. Can you try with your use case ? 2012/4/26 Stephen Connolly stephen.alan.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
Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 2)
2012/4/29 Anders Hammar and...@hammar.net: 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 ol...@apache.org wrote: ok in order to try make all happy :-) I will make that configurable. @Anders I have pushed a snapshot with a new flag called mergeUserSettings. Can you try with your use case ? 2012/4/26 Stephen Connolly stephen.alan.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
Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 2)
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 ol...@apache.org wrote: ok in order to try make all happy :-) I will make that configurable. @Anders I have pushed a snapshot with a new flag called mergeUserSettings. Can you try with your use case ? 2012/4/26 Stephen Connolly stephen.alan.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
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
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:
[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: 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)
+1 (non-binding) /Anders On Wed, Apr 25, 2012 at 10:53, Olivier Lamy ol...@apache.org 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: 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)
Hi, -1 (non binding) based on my reported problems... 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)
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-settingsxml)... 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: settingsFilesrc/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 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)
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 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
