Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 3)
Here my +1. 2012/5/21 Olivier Lamy ol...@apache.org: Hi, I'd like to release Apache Maven Invoker plugin 1.6. We fixed 16 issues ( release notes: http://s.apache.org/MINVOKER-1.6 ) Staging repository: https://repository.apache.org/content/repositories/maven-104/ 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 -- 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
[RESULT] [VOTE] Apache Maven Invoker Plugin 1.6
Hi, The vote has passed with the following result: +1 (binding): Mark Struberg, Stephen Connolly, Olivier Lamy +1 (non-binding): LeClaire Garvin, Anders Hammar I will continue release process. 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 3)
+1 (non-binding) Thanks Olivier! /Anders On Mon, May 21, 2012 at 4:16 PM, LeClaire Garvin garvin.lecla...@gmail.com wrote: +1 non-binding Regards, Garvin LeClaire garvin.lecla...@gmail.com On May 21, 2012, at 9:51 AM, Olivier Lamy wrote: Hi, I'd like to release Apache Maven Invoker plugin 1.6. We fixed 16 issues ( release notes: http://s.apache.org/MINVOKER-1.6 ) Staging repository: https://repository.apache.org/content/repositories/maven-104/ 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 - 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 3)
+1 LieGrue, strub - Original Message - From: Anders Hammar and...@hammar.net To: Maven Developers List dev@maven.apache.org Cc: Sent: Tuesday, May 22, 2012 11:22 AM Subject: Re: [VOTE] Apache Maven Invoker Plugin 1.6 (take 3) +1 (non-binding) Thanks Olivier! /Anders On Mon, May 21, 2012 at 4:16 PM, LeClaire Garvin garvin.lecla...@gmail.com wrote: +1 non-binding Regards, Garvin LeClaire garvin.lecla...@gmail.com On May 21, 2012, at 9:51 AM, Olivier Lamy wrote: Hi, I'd like to release Apache Maven Invoker plugin 1.6. We fixed 16 issues ( release notes: http://s.apache.org/MINVOKER-1.6 ) Staging repository: https://repository.apache.org/content/repositories/maven-104/ 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 - 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 3)
+1 (binding) On 21 May 2012 14:51, Olivier Lamy ol...@apache.org wrote: Hi, I'd like to release Apache Maven Invoker plugin 1.6. We fixed 16 issues ( release notes: http://s.apache.org/MINVOKER-1.6 ) Staging repository: https://repository.apache.org/content/repositories/maven-104/ 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)
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 ).
[VOTE] Apache Maven Invoker Plugin 1.6 (take 3)
Hi, I'd like to release Apache Maven Invoker plugin 1.6. We fixed 16 issues ( release notes: http://s.apache.org/MINVOKER-1.6 ) Staging repository: https://repository.apache.org/content/repositories/maven-104/ 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 3)
+1 non-binding Regards, Garvin LeClaire garvin.lecla...@gmail.com On May 21, 2012, at 9:51 AM, Olivier Lamy wrote: Hi, I'd like to release Apache Maven Invoker plugin 1.6. We fixed 16 issues ( release notes: http://s.apache.org/MINVOKER-1.6 ) Staging repository: https://repository.apache.org/content/repositories/maven-104/ 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)
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: Issue with parallelThreads Re: [VOTE] Apache Maven Invoker Plugin 1.6
Hi Oliver, sorry for late answer ...but here is the result with settings parallelThreads to 5... [INFO] Installing /home/build/wc/appassembler/appassembler-maven-plugin/pom.xml to /home/build/wc/appassembler/appassembler-maven-plugin/target/local-repo/org/codehaus/mojo/appassembler-maven-plugin/1.2.2-SNAPSHOT/appassembler-maven-plugin-1.2.2-SNAPSHOT.pom [INFO] Installing /home/build/wc/appassembler/appassembler-maven-plugin/target/appassembler-maven-plugin-1.2.2-SNAPSHOT.jar to /home/build/wc/appassembler/appassembler-maven-plugin/target/local-repo/org/codehaus/mojo/appassembler-maven-plugin/1.2.2-SNAPSHOT/appassembler-maven-plugin-1.2.2-SNAPSHOT.jar [INFO] [INFO] --- maven-invoker-plugin:1.6:run (integration-tests) @ appassembler-maven-plugin --- [INFO] use parallelThreads 5 [INFO] Building: assembleDirectoryTest/pom.xml [INFO] Building: programJvmArgumentsTest/pom.xml [INFO] Building: binFileExtensionTest/pom.xml [INFO] Building: binFolderTest/pom.xml [INFO] Building: daemonTest/pom.xml [INFO] ..FAILED (5.0 s) [INFO] The build exited with code 1. See /home/build/wc/appassembler/appassembler-maven-plugin/target/it/assembleDirectoryTest/build.log for details. [INFO] Building: configurationDirectoryTest/pom.xml [INFO] ..FAILED (5.4 s) [INFO] The build exited with code 1. See /home/build/wc/appassembler/appassembler-maven-plugin/target/it/daemonTest/build.log for details. [INFO] Building: MAPPASM-145-Test/pom.xml [INFO] run script /home/build/wc/appassembler/appassembler-maven-plugin/target/it/programJvmArgumentsTest/verify.groovy [INFO] ..SUCCESS (10.1 s) [INFO] Building: asterikClassPathTest/pom.xml [INFO] run script /home/build/wc/appassembler/appassembler-maven-plugin/target/it/configurationDirectoryTest/verify.groovy [INFO] ..SUCCESS (6.1 s) [INFO] Building: asterikClassPathWrongConfigurationTest/pom.xml [INFO] run script /home/build/wc/appassembler/appassembler-maven-plugin/target/it/MAPPASM-145-Test/verify.groovy [INFO] ..SUCCESS (10.6 s) [INFO] Building: repositoryLayoutLegacyTest/pom.xml [INFO] ..SKIPPED [INFO] Building: daemonConfigurationTest/pom.xml [INFO] run script /home/build/wc/appassembler/appassembler-maven-plugin/target/it/systemDependencyTest/verify.groovy [INFO] ..SUCCESS (7.6 s) [INFO] Building: basicTest/pom.xml [INFO] run script /home/build/wc/appassembler/appassembler-maven-plugin/target/it/asterikClassPathTest/verify.groovy [INFO] ..SUCCESS (7.7 s) [INFO] Building: generateRepositoryTest/pom.xml [INFO] run script /home/build/wc/appassembler/appassembler-maven-plugin/target/it/asterikClassPathWrongConfigurationTest/verify.groovy [INFO] ..SUCCESS (6.9 s) [INFO] Building: configurationSourceDirectoryTest/pom.xml [INFO] run script /home/build/wc/appassembler/appassembler-maven-plugin/target/it/daemonConfigurationTest/verify.groovy [INFO] ..SUCCESS (7.4 s) [INFO] Building: daemonMultipleTest/pom.xml [INFO] run script /home/build/wc/appassembler/appassembler-maven-plugin/target/it/basicTest/verify.groovy [INFO] ..SUCCESS (7.4 s) [INFO] Building: programNameDuplicateTest/pom.xml [INFO] run script /home/build/wc/appassembler/appassembler-maven-plugin/target/it/environmentSetupTest/verify.groovy [INFO] ..SUCCESS (7.6 s) [INFO] Building: MAPPASM-108-Test/pom.xml But after that i have change the configuration only and removed the configuration point for parallelThreads so the default of 1 will be used with the following (expected result): lugin-1.2.2-SNAPSHOT.jar [INFO] [INFO] --- maven-invoker-plugin:1.6:run (integration-tests) @ appassembler-maven-plugin --- [INFO] Building: assembleDirectoryTest/pom.xml [INFO] run script /home/build/wc/appassembler/appassembler-maven-plugin/target/it/assembleDirectoryTest/verify.groovy [INFO] ..SUCCESS (6.4 s) [INFO] Building: programJvmArgumentsTest/pom.xml [INFO] run script /home/build/wc/appassembler/appassembler-maven-plugin/target/it/programJvmArgumentsTest/verify.groovy [INFO] ..SUCCESS (3.1 s) [INFO] Building: binFileExtensionTest/pom.xml [INFO] run script /home/build/wc/appassembler/appassembler-maven-plugin/target/it/binFileExtensionTest/verify.groovy [INFO] ..SUCCESS (3.9 s) [INFO] Building: binFolderTest/pom.xml [INFO] run script /home/build/wc/appassembler/appassembler-maven-plugin/target/it/binFolderTest/verify.groovy [INFO] ..SUCCESS (3.6 s) [INFO] Building: daemonTest/pom.xml [INFO] run script /home/build/wc/appassembler/appassembler-maven-plugin/target/it/daemonTest/verify.groovy [INFO] ..SUCCESS (3.4 s) [INFO] Building: configurationDirectoryTest/pom.xml [INFO] run script /home/build/wc/appassembler/appassembler-maven-plugin/target/it/configurationDirectoryTest/verify.groovy [INFO] ..SUCCESS (3.6 s) [INFO] Building: MAPPASM-145-Test/pom.xml [INFO] run script /home/build/wc/appassembler/appassembler-maven-plugin/target/it/MAPPASM-145-Test/verify.groovy [INFO] ..SUCCESS (4.8 s) [INFO] Building: programCLIArgumentsWithExpandingTest/pom.xml [INFO] run script
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
Re: Issue with parallelThreads Re: [VOTE] Apache Maven Invoker Plugin 1.6
I'm interested to know the content of those build.log files. Note using parallel feature, you will need some resources on the machine running build because if you have a MAVEN_OPTS with a huge mx/ms this will be multiplicated by the number of parallel thread you are configuring. This parallelThreads simply means you will run x Maven build + the current one (so take care of resources on the machine) 2012/4/25 Karl Heinz Marbaise khmarba...@gmx.de: Hi Oliver, sorry for late answer ...but here is the result with settings parallelThreads to 5... [INFO] Installing /home/build/wc/appassembler/appassembler-maven-plugin/pom.xml to /home/build/wc/appassembler/appassembler-maven-plugin/target/local-repo/org/codehaus/mojo/appassembler-maven-plugin/1.2.2-SNAPSHOT/appassembler-maven-plugin-1.2.2-SNAPSHOT.pom [INFO] Installing /home/build/wc/appassembler/appassembler-maven-plugin/target/appassembler-maven-plugin-1.2.2-SNAPSHOT.jar to /home/build/wc/appassembler/appassembler-maven-plugin/target/local-repo/org/codehaus/mojo/appassembler-maven-plugin/1.2.2-SNAPSHOT/appassembler-maven-plugin-1.2.2-SNAPSHOT.jar [INFO] [INFO] --- maven-invoker-plugin:1.6:run (integration-tests) @ appassembler-maven-plugin --- [INFO] use parallelThreads 5 [INFO] Building: assembleDirectoryTest/pom.xml [INFO] Building: programJvmArgumentsTest/pom.xml [INFO] Building: binFileExtensionTest/pom.xml [INFO] Building: binFolderTest/pom.xml [INFO] Building: daemonTest/pom.xml [INFO] ..FAILED (5.0 s) [INFO] The build exited with code 1. See /home/build/wc/appassembler/appassembler-maven-plugin/target/it/assembleDirectoryTest/build.log for details. [INFO] Building: configurationDirectoryTest/pom.xml [INFO] ..FAILED (5.4 s) [INFO] The build exited with code 1. See /home/build/wc/appassembler/appassembler-maven-plugin/target/it/daemonTest/build.log for details. [INFO] Building: MAPPASM-145-Test/pom.xml [INFO] run script /home/build/wc/appassembler/appassembler-maven-plugin/target/it/programJvmArgumentsTest/verify.groovy [INFO] ..SUCCESS (10.1 s) [INFO] Building: asterikClassPathTest/pom.xml [INFO] run script /home/build/wc/appassembler/appassembler-maven-plugin/target/it/configurationDirectoryTest/verify.groovy [INFO] ..SUCCESS (6.1 s) [INFO] Building: asterikClassPathWrongConfigurationTest/pom.xml [INFO] run script /home/build/wc/appassembler/appassembler-maven-plugin/target/it/MAPPASM-145-Test/verify.groovy [INFO] ..SUCCESS (10.6 s) [INFO] Building: repositoryLayoutLegacyTest/pom.xml [INFO] ..SKIPPED [INFO] Building: daemonConfigurationTest/pom.xml [INFO] run script /home/build/wc/appassembler/appassembler-maven-plugin/target/it/systemDependencyTest/verify.groovy [INFO] ..SUCCESS (7.6 s) [INFO] Building: basicTest/pom.xml [INFO] run script /home/build/wc/appassembler/appassembler-maven-plugin/target/it/asterikClassPathTest/verify.groovy [INFO] ..SUCCESS (7.7 s) [INFO] Building: generateRepositoryTest/pom.xml [INFO] run script /home/build/wc/appassembler/appassembler-maven-plugin/target/it/asterikClassPathWrongConfigurationTest/verify.groovy [INFO] ..SUCCESS (6.9 s) [INFO] Building: configurationSourceDirectoryTest/pom.xml [INFO] run script /home/build/wc/appassembler/appassembler-maven-plugin/target/it/daemonConfigurationTest/verify.groovy [INFO] ..SUCCESS (7.4 s) [INFO] Building: daemonMultipleTest/pom.xml [INFO] run script /home/build/wc/appassembler/appassembler-maven-plugin/target/it/basicTest/verify.groovy [INFO] ..SUCCESS (7.4 s) [INFO] Building: programNameDuplicateTest/pom.xml [INFO] run script /home/build/wc/appassembler/appassembler-maven-plugin/target/it/environmentSetupTest/verify.groovy [INFO] ..SUCCESS (7.6 s) [INFO] Building: MAPPASM-108-Test/pom.xml But after that i have change the configuration only and removed the configuration point for parallelThreads so the default of 1 will be used with the following (expected result): lugin-1.2.2-SNAPSHOT.jar [INFO] [INFO] --- maven-invoker-plugin:1.6:run (integration-tests) @ appassembler-maven-plugin --- [INFO] Building: assembleDirectoryTest/pom.xml [INFO] run script /home/build/wc/appassembler/appassembler-maven-plugin/target/it/assembleDirectoryTest/verify.groovy [INFO] ..SUCCESS (6.4 s) [INFO] Building: programJvmArgumentsTest/pom.xml [INFO] run script /home/build/wc/appassembler/appassembler-maven-plugin/target/it/programJvmArgumentsTest/verify.groovy [INFO] ..SUCCESS (3.1 s) [INFO] Building: binFileExtensionTest/pom.xml [INFO] run script /home/build/wc/appassembler/appassembler-maven-plugin/target/it/binFileExtensionTest/verify.groovy [INFO] ..SUCCESS (3.9 s) [INFO] Building: binFolderTest/pom.xml [INFO] run script /home/build/wc/appassembler/appassembler-maven-plugin/target/it/binFolderTest/verify.groovy [INFO] ..SUCCESS (3.6 s) [INFO] Building: daemonTest/pom.xml [INFO] run script /home/build/wc/appassembler/appassembler-maven-plugin/target/it/daemonTest/verify.groovy [INFO] ..SUCCESS
Re: [VOTE] Apache Maven Invoker Plugin 1.6
See http://maven.apache.org/doxia/issues/index.html#Verbatim_blocks_not_boxed I have fixed the apt sources. Cheers, -Lukas Karl Heinz Marbaise wrote: Hi, i have checked the staged Site and observed that the frames around the source examples or code snippet are not there... For example if you compare http://maven.apache.org/plugins/maven-invoker-plugin-1.6/examples/invoker-properties.html http://maven.apache.org/plugins/maven-invoker-plugin/examples/invoker-properties.html I assume this is based on the staging site ? Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Issue with parallelThreads Re: [VOTE] Apache Maven Invoker Plugin 1.6
Thanks Lukas for the fix. I have fixed too the parallelThreads trouble. @Karl can you test with your projects ? Thanks 2012/4/24 Lukas Theussl ltheu...@apache.org: See http://maven.apache.org/doxia/issues/index.html#Verbatim_blocks_not_boxed I have fixed the apt sources. Cheers, -Lukas Karl Heinz Marbaise wrote: Hi, i have checked the staged Site and observed that the frames around the source examples or code snippet are not there... For example if you compare http://maven.apache.org/plugins/maven-invoker-plugin-1.6/examples/invoker-properties.html http://maven.apache.org/plugins/maven-invoker-plugin/examples/invoker-properties.html I assume this is based on the staging site ? Kind regards Karl Heinz Marbaise - 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] Apache Maven Invoker Plugin 1.6
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-082/ Staging site: http://maven.apache.org/plugins/maven-invoker-plugin-1.6/ 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
+1 (non-binding) Thanks, /Anders On Mon, Apr 23, 2012 at 14:22, 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-082/ Staging site: http://maven.apache.org/plugins/maven-invoker-plugin-1.6/ 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
Hi, i just tested it on the current state of the appassembler-plugin (trunk) with integration-tests but results into the following. I have added simply parrallelThreads3/parrallelThreads to my configuration for the invoker-plugin plus of course the version to 1.6... May be i oversight something ? [INFO] [INFO] --- maven-invoker-plugin:1.6:run (integration-tests) @ appassembler-maven-plugin --- [INFO] use parrallelThreads 3 [INFO] Building: assembleDirectoryTest/pom.xml [INFO] Building: asterikClassPathTest/pom.xml [INFO] Building: asterikClassPathWrongConfigurationTest/pom.xml Exception in thread pool-101-thread-2 java.lang.IllegalStateException: Cannot reset sourceLevel attribute; it is already set to: user-level at org.apache.maven.settings.TrackableBase.setSourceLevel(TrackableBase.java:60) at org.apache.maven.settings.merge.MavenSettingsMerger.merge(MavenSettingsMerger.java:50) at org.apache.maven.settings.SettingsUtils.merge(SettingsUtils.java:47) at org.apache.maven.plugin.invoker.AbstractInvokerMojo.runBuild(AbstractInvokerMojo.java:1359) at org.apache.maven.plugin.invoker.AbstractInvokerMojo.runBuild(AbstractInvokerMojo.java:1138) at org.apache.maven.plugin.invoker.AbstractInvokerMojo.access$000(AbstractInvokerMojo.java:96) at org.apache.maven.plugin.invoker.AbstractInvokerMojo$1.run(AbstractInvokerMojo.java:1035) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:680) Exception in thread pool-101-thread-3 java.lang.IllegalStateException: Cannot reset sourceLevel attribute; it is already set to: user-level at org.apache.maven.settings.TrackableBase.setSourceLevel(TrackableBase.java:60) at org.apache.maven.settings.merge.MavenSettingsMerger.merge(MavenSettingsMerger.java:50) at org.apache.maven.settings.SettingsUtils.merge(SettingsUtils.java:47) at org.apache.maven.plugin.invoker.AbstractInvokerMojo.runBuild(AbstractInvokerMojo.java:1359) at org.apache.maven.plugin.invoker.AbstractInvokerMojo.runBuild(AbstractInvokerMojo.java:1138) at org.apache.maven.plugin.invoker.AbstractInvokerMojo.access$000(AbstractInvokerMojo.java:96) at org.apache.maven.plugin.invoker.AbstractInvokerMojo$1.run(AbstractInvokerMojo.java:1035) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:680) [INFO] run script /Users/km/workspace/appassembler/appassembler-maven-plugin/target/it/assembleDirectoryTest/verify.groovy The environment was the following: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) Maven home: /usr/share/maven Java version: 1.6.0_26, vendor: Apple Inc. Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home Default locale: en_US, platform encoding: MacRoman OS name: mac os x, version: 10.5.8, arch: x86_64, family: mac 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
Hi, just tested an other project (https://github.com/khmarbaise/Maven-License-Verifier-Plugin) I have added simply parrallelThreads3/parrallelThreads to my configuration for the invoker-plugin plus of course the version to 1.6... with the following result: [INFO] [INFO] --- maven-invoker-plugin:1.6:run (integration-test) @ maven-license-verifier-plugin --- [INFO] Building: mlv-setup/pom.xml [INFO] ..SUCCESS (7.3 s) [INFO] Building: mlv-setup-different-location/pom.xml [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 35.305s [INFO] Finished at: Mon Apr 23 22:38:59 CEST 2012 [INFO] Final Memory: 18M/528M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-invoker-plugin:1.6:run (integration-test) on project maven-license-verifier-plugin: Execution integration-test of goal org.apache.maven.plugins:maven-invoker-plugin:1.6:run failed: Cannot reset sourceLevel attribute; it is already set to: user-level - [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException 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
Hi, i have checked the staged Site and observed that the frames around the source examples or code snippet are not there... For example if you compare http://maven.apache.org/plugins/maven-invoker-plugin-1.6/examples/invoker-properties.html http://maven.apache.org/plugins/maven-invoker-plugin/examples/invoker-properties.html I assume this is based on the staging site ? 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
[CANCEL] [VOTE] Apache Maven Invoker Plugin 1.6
good catch too. I didn't test the parrallelThreads stuff So I cancel the vote. 2012/4/23 Karl Heinz Marbaise khmarba...@gmx.de: Hi, i have checked the staged Site and observed that the frames around the source examples or code snippet are not there... For example if you compare http://maven.apache.org/plugins/maven-invoker-plugin-1.6/examples/invoker-properties.html http://maven.apache.org/plugins/maven-invoker-plugin/examples/invoker-properties.html I assume this is based on the staging site ? 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: [CANCEL] [VOTE] Apache Maven Invoker Plugin 1.6
While you're there, parallel rather than parrallel, please! On 23/04/12 05:14 PM, Olivier Lamy wrote: good catch too. I didn't test the parrallelThreads stuff So I cancel the vote. 2012/4/23 Karl Heinz Marbaisekhmarba...@gmx.de: Hi, i have checked the staged Site and observed that the frames around the source examples or code snippet are not there... For example if you compare http://maven.apache.org/plugins/maven-invoker-plugin-1.6/examples/invoker-properties.html http://maven.apache.org/plugins/maven-invoker-plugin/examples/invoker-properties.html I assume this is based on the staging site ? 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 -- Fighting a war is easy. Destroying is easy. Building a new world out of what's left of the old, that is what's hard. —J. Michael Straczynski - 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
HI, I have added simply parrallelThreads3/parrallelThreads Of course this should be written: parallelThreads... Just a typo... 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