Re: [BUG] spell mistake, Log4JLoggerFactory should be Log4jLoggerFactory
Am 2014-10-28 um 03:17 schrieb yanshuai: hi, all, I found a mistake in slf4j-configuration.properties of maven-embedder project, org.slf4j.helpers.Log4JLoggerFactory should be org.slf4j.helpers.Log4jLoggerFactory. Otherwise, when I use log4j2 instead of slf4j-simple, it will not find the class org.slf4j.helpers.Log4JLoggerFactory and generate some unexpected warnings. Hope to fix it in the next version, thanks. http://jira.codehaus.org/browse/MNG - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Archiver version 2.6
Nexus operation has been resumed. Please vote/test. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Proposal: Ease the usage of Failsafe
Hi, I see a lot of people using *Surefire for intergation tests instead of Failsafe*. I think the reason for this is that *Failsafe* is from my perspective is *not integrated* in Maven *as is possible*. While unittest (*Test.java) are executed if we place them in |src/test/java| for integrationtests we have to add |build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-failsafe-plugin/artifactId executions execution phaseintegration-test/phase goals goalintegration-test/goal goalverify/goal /goals /execution /executions /plugin /plugins /build | Why is is not possible to integrate Failsafe in the same convenient way as Surefire. I prepared a small example project you can checkout via Git |git clone https://bitbucket.org/obfischer/bugreport-maven-failsafe.git | Integrating Failsafe in the same way as Surefire would be great for a lot of people I think. Oliver
Re: Proposal: Ease the usage of Failsafe
I have always used surefire for integration tests with a Maven profile (to activate them on demand since they are time consuming). What benefit am I missing not using failsafe? Cheers, Paul On Tue, Oct 28, 2014 at 5:26 AM, Oliver B. Fischer mails...@swe-blog.net wrote: Hi, I see a lot of people using *Surefire for intergation tests instead of Failsafe*. I think the reason for this is that *Failsafe* is from my perspective is *not integrated* in Maven *as is possible*. While unittest (*Test.java) are executed if we place them in |src/test/java| for integrationtests we have to add |build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-failsafe-plugin/artifactId executions execution phaseintegration-test/phase goals goalintegration-test/goal goalverify/goal /goals /execution /executions /plugin /plugins /build | Why is is not possible to integrate Failsafe in the same convenient way as Surefire. I prepared a small example project you can checkout via Git |git clone https://bitbucket.org/obfischer/bugreport-maven-failsafe.git | Integrating Failsafe in the same way as Surefire would be great for a lot of people I think. Oliver
Re: Proposal: Ease the usage of Failsafe
The answer is on the index page of the failsafe plugin [1]. If you use the Surefire Plugin for running tests... /Anders [1] http://maven.apache.org/surefire/maven-failsafe-plugin/ On Tue, Oct 28, 2014 at 3:18 PM, Paul Benedict pbened...@apache.org wrote: I have always used surefire for integration tests with a Maven profile (to activate them on demand since they are time consuming). What benefit am I missing not using failsafe? Cheers, Paul On Tue, Oct 28, 2014 at 5:26 AM, Oliver B. Fischer mails...@swe-blog.net wrote: Hi, I see a lot of people using *Surefire for intergation tests instead of Failsafe*. I think the reason for this is that *Failsafe* is from my perspective is *not integrated* in Maven *as is possible*. While unittest (*Test.java) are executed if we place them in |src/test/java| for integrationtests we have to add |build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-failsafe-plugin/artifactId executions execution phaseintegration-test/phase goals goalintegration-test/goal goalverify/goal /goals /execution /executions /plugin /plugins /build | Why is is not possible to integrate Failsafe in the same convenient way as Surefire. I prepared a small example project you can checkout via Git |git clone https://bitbucket.org/obfischer/bugreport-maven-failsafe.git | Integrating Failsafe in the same way as Surefire would be great for a lot of people I think. Oliver
Re: Proposal: Ease the usage of Failsafe
Thanks. Now I know when to use this. For my situation, which is integration testing against an existing database, I don't need to setup an environment; this explains why I never needed to use the plugin. There are other cases the plugin will be valuable, but I wonder if this is why most others stick with surefire. I guess programmers don't scratch unless there's an itch. Cheers, Paul On Tue, Oct 28, 2014 at 9:21 AM, Anders Hammar and...@hammar.net wrote: The answer is on the index page of the failsafe plugin [1]. If you use the Surefire Plugin for running tests... /Anders [1] http://maven.apache.org/surefire/maven-failsafe-plugin/ On Tue, Oct 28, 2014 at 3:18 PM, Paul Benedict pbened...@apache.org wrote: I have always used surefire for integration tests with a Maven profile (to activate them on demand since they are time consuming). What benefit am I missing not using failsafe? Cheers, Paul On Tue, Oct 28, 2014 at 5:26 AM, Oliver B. Fischer mails...@swe-blog.net wrote: Hi, I see a lot of people using *Surefire for intergation tests instead of Failsafe*. I think the reason for this is that *Failsafe* is from my perspective is *not integrated* in Maven *as is possible*. While unittest (*Test.java) are executed if we place them in |src/test/java| for integrationtests we have to add |build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-failsafe-plugin/artifactId executions execution phaseintegration-test/phase goals goalintegration-test/goal goalverify/goal /goals /execution /executions /plugin /plugins /build | Why is is not possible to integrate Failsafe in the same convenient way as Surefire. I prepared a small example project you can checkout via Git |git clone https://bitbucket.org/obfischer/bugreport-maven-failsafe.git | Integrating Failsafe in the same way as Surefire would be great for a lot of people I think. Oliver
Re: Proposal: Ease the usage of Failsafe
@Paul: Yes I think so or we find a way more convenient in this moment. @all: I think this shows perfectly why Failsafe should be integrated as Surefire already is. Oliver Am 28.10.14 16:02, schrieb Paul Benedict: Thanks. Now I know when to use this. For my situation, which is integration testing against an existing database, I don't need to setup an environment; this explains why I never needed to use the plugin. There are other cases the plugin will be valuable, but I wonder if this is why most others stick with surefire. I guess programmers don't scratch unless there's an itch. Cheers, Paul On Tue, Oct 28, 2014 at 9:21 AM, Anders Hammar and...@hammar.net wrote: The answer is on the index page of the failsafe plugin [1]. If you use the Surefire Plugin for running tests... /Anders [1] http://maven.apache.org/surefire/maven-failsafe-plugin/ On Tue, Oct 28, 2014 at 3:18 PM, Paul Benedict pbened...@apache.org wrote: (to mails...@swe-blog.net https://bitbucket.org/obfischer/bugreport-maven-failsafe.git lot - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Proposal: Ease the usage of Failsafe
Personally, I wonder why we don't merge them. Failsafe adds some lifestyle phase bindings and then changes some defaults. Otherwise, it's a giant anti-DRY. Why not expand surefire to have the extra executions with shifted defaults for things like test class names? On Tue, Oct 28, 2014 at 11:50 AM, Oliver B. Fischer mails...@swe-blog.net wrote: @Paul: Yes I think so or we find a way more convenient in this moment. @all: I think this shows perfectly why Failsafe should be integrated as Surefire already is. Oliver Am 28.10.14 16:02, schrieb Paul Benedict: Thanks. Now I know when to use this. For my situation, which is integration testing against an existing database, I don't need to setup an environment; this explains why I never needed to use the plugin. There are other cases the plugin will be valuable, but I wonder if this is why most others stick with surefire. I guess programmers don't scratch unless there's an itch. Cheers, Paul On Tue, Oct 28, 2014 at 9:21 AM, Anders Hammar and...@hammar.net wrote: The answer is on the index page of the failsafe plugin [1]. If you use the Surefire Plugin for running tests... /Anders [1] http://maven.apache.org/surefire/maven-failsafe-plugin/ On Tue, Oct 28, 2014 at 3:18 PM, Paul Benedict pbened...@apache.org wrote: (to mails...@swe-blog.net https://bitbucket.org/obfischer/bugreport-maven-failsafe.git lot - 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: Proposal: Ease the usage of Failsafe
Integrating Failsafe in the same way as Surefire would be great for a lot of people I think. I agree! Personally, I wonder why we don't merge them. I've wondered the same thing... is there a technical reason why it won't or is difficult to make work? On Tue, Oct 28, 2014 at 11:54 AM, Benson Margulies bimargul...@gmail.com wrote: Personally, I wonder why we don't merge them. Failsafe adds some lifestyle phase bindings and then changes some defaults. Otherwise, it's a giant anti-DRY. Why not expand surefire to have the extra executions with shifted defaults for things like test class names? On Tue, Oct 28, 2014 at 11:50 AM, Oliver B. Fischer mails...@swe-blog.net wrote: @Paul: Yes I think so or we find a way more convenient in this moment. @all: I think this shows perfectly why Failsafe should be integrated as Surefire already is. Oliver Am 28.10.14 16:02, schrieb Paul Benedict: Thanks. Now I know when to use this. For my situation, which is integration testing against an existing database, I don't need to setup an environment; this explains why I never needed to use the plugin. There are other cases the plugin will be valuable, but I wonder if this is why most others stick with surefire. I guess programmers don't scratch unless there's an itch. Cheers, Paul On Tue, Oct 28, 2014 at 9:21 AM, Anders Hammar and...@hammar.net wrote: The answer is on the index page of the failsafe plugin [1]. If you use the Surefire Plugin for running tests... /Anders [1] http://maven.apache.org/surefire/maven-failsafe-plugin/ On Tue, Oct 28, 2014 at 3:18 PM, Paul Benedict pbened...@apache.org wrote: (to mails...@swe-blog.net https://bitbucket.org/obfischer/bugreport-maven-failsafe.git lot - 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: Proposal: Ease the usage of Failsafe
If my memory serves me right, the failsafe plugin was conceived/developed by a third party -- perhaps codehaus. Then it was later adapted by Apache. I think this is maybe why the two haven't been merged (yet). Cheers, Paul On Tue, Oct 28, 2014 at 12:06 PM, Jeff Jensen jeffjen...@upstairstechnology.com wrote: Integrating Failsafe in the same way as Surefire would be great for a lot of people I think. I agree! Personally, I wonder why we don't merge them. I've wondered the same thing... is there a technical reason why it won't or is difficult to make work? On Tue, Oct 28, 2014 at 11:54 AM, Benson Margulies bimargul...@gmail.com wrote: Personally, I wonder why we don't merge them. Failsafe adds some lifestyle phase bindings and then changes some defaults. Otherwise, it's a giant anti-DRY. Why not expand surefire to have the extra executions with shifted defaults for things like test class names? On Tue, Oct 28, 2014 at 11:50 AM, Oliver B. Fischer mails...@swe-blog.net wrote: @Paul: Yes I think so or we find a way more convenient in this moment. @all: I think this shows perfectly why Failsafe should be integrated as Surefire already is. Oliver Am 28.10.14 16:02, schrieb Paul Benedict: Thanks. Now I know when to use this. For my situation, which is integration testing against an existing database, I don't need to setup an environment; this explains why I never needed to use the plugin. There are other cases the plugin will be valuable, but I wonder if this is why most others stick with surefire. I guess programmers don't scratch unless there's an itch. Cheers, Paul On Tue, Oct 28, 2014 at 9:21 AM, Anders Hammar and...@hammar.net wrote: The answer is on the index page of the failsafe plugin [1]. If you use the Surefire Plugin for running tests... /Anders [1] http://maven.apache.org/surefire/maven-failsafe-plugin/ On Tue, Oct 28, 2014 at 3:18 PM, Paul Benedict pbened...@apache.org wrote: (to mails...@swe-blog.net https://bitbucket.org/obfischer/bugreport-maven-failsafe.git lot - 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: Proposal: Ease the usage of Failsafe
I wrote it before I had my apache commit bit. there are pluses and minuses to combining them. For instance it is harder to configure different defaults for goals when they are the same plugin. But in any case, for either path changing the bindings to make them easier to use will still require adjusting the default lifecycle and introducing plugin bindings to the default lifecycle... we need to take care in doing that On 28 October 2014 17:22, Paul Benedict pbened...@apache.org wrote: If my memory serves me right, the failsafe plugin was conceived/developed by a third party -- perhaps codehaus. Then it was later adapted by Apache. I think this is maybe why the two haven't been merged (yet). Cheers, Paul On Tue, Oct 28, 2014 at 12:06 PM, Jeff Jensen jeffjen...@upstairstechnology.com wrote: Integrating Failsafe in the same way as Surefire would be great for a lot of people I think. I agree! Personally, I wonder why we don't merge them. I've wondered the same thing... is there a technical reason why it won't or is difficult to make work? On Tue, Oct 28, 2014 at 11:54 AM, Benson Margulies bimargul...@gmail.com wrote: Personally, I wonder why we don't merge them. Failsafe adds some lifestyle phase bindings and then changes some defaults. Otherwise, it's a giant anti-DRY. Why not expand surefire to have the extra executions with shifted defaults for things like test class names? On Tue, Oct 28, 2014 at 11:50 AM, Oliver B. Fischer mails...@swe-blog.net wrote: @Paul: Yes I think so or we find a way more convenient in this moment. @all: I think this shows perfectly why Failsafe should be integrated as Surefire already is. Oliver Am 28.10.14 16:02, schrieb Paul Benedict: Thanks. Now I know when to use this. For my situation, which is integration testing against an existing database, I don't need to setup an environment; this explains why I never needed to use the plugin. There are other cases the plugin will be valuable, but I wonder if this is why most others stick with surefire. I guess programmers don't scratch unless there's an itch. Cheers, Paul On Tue, Oct 28, 2014 at 9:21 AM, Anders Hammar and...@hammar.net wrote: The answer is on the index page of the failsafe plugin [1]. If you use the Surefire Plugin for running tests... /Anders [1] http://maven.apache.org/surefire/maven-failsafe-plugin/ On Tue, Oct 28, 2014 at 3:18 PM, Paul Benedict pbened...@apache.org wrote: (to mails...@swe-blog.net https://bitbucket.org/obfischer/bugreport-maven-failsafe.git lot - 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
Who evaluates menu ref=parent|modules / in site.xml?
Hi, I'd like to fix MPIR-279 and by applying the logic from above. I am having a hard time to find that spot which actually evalutes the snippet above. Does someone know? Thanks, Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Archiver version 2.6
Hi, checked SHA1 Ok.. tested with Maven 2.2.1, 3.0.5, 3.1.1, 3.2.1, 3.2.2, 3.2.3 no issues found. So +1 from me... Unfortunately the number of checkstyle errors has increased from 29 in version 2.5 to 39 in version 2.6...created an appropriate jira for it http://jira.codehaus.org/browse/MSHARED-380 Kind regards Karl Heinz Marbaise On 10/26/14 10:06 PM, Michael Osipov wrote: Hi, We solved 9 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=18325projectId=11761 There are still a couple of issues left in JIRA: http://jira.codehaus.org/browse/MSHARED-168?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1086/ http://repository.apache.org/content/repositories/maven-1086/org/apache/maven/maven-archiver/2.6/maven-archiver-2.6-source-release.zip Source release checksum(s): maven-archiver-2.6-source-release.zip sha1: 1abc6527f6a3ce037db8c3bc549bb07876f4347a Staging site: http://maven.apache.org/shared-archives/maven-archiver-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Clean Plugin version 2.6.1
Hi, here my +1... Kind regards Karl Heinz Marbaise On 10/26/14 8:48 PM, Karl Heinz Marbaise wrote: Hi, We solved 6 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11128version=20685 There are still 2 issues left in JIRA: http://jira.codehaus.org/issues/?jql=project%20%3D%20MCLEAN%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1085 http://repository.apache.org/content/repositories/maven-1085/org/apache/maven/plugins/maven-clean-plugin/2.6.1/maven-clean-plugin-2.6.1-source-release.zip Source release checksum(s): maven-clean-plugin-source-release.zip sha1: ef240a899fe1e7425e96ece23d3d75c9ec268782 Staging site: http://maven.apache.org/plugins-archives/maven-clean-plugin-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Archiver version 2.6
Am 2014-10-28 um 20:31 schrieb Karl Heinz Marbaise: Hi, checked SHA1 Ok.. tested with Maven 2.2.1, 3.0.5, 3.1.1, 3.2.1, 3.2.2, 3.2.3 no issues found. So +1 from me... Unfortunately the number of checkstyle errors has increased from 29 in version 2.5 to 39 in version 2.6...created an appropriate jira for it http://jira.codehaus.org/browse/MSHARED-380 I'll have a look after the release. Why below 29? Is that a magic number? Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Proposal: Ease the usage of Failsafe
Hi, i'm completely against merging maven-failsafe-plugin into the life cycle... Running maven-failsafe-plugin within integration-test phase is one solution...but sometimes you have other things to do for integration tests In pre-integration-test phase it's often the case to start an application server / servlet engine or whatever kind of server (for example using cargo-maven2-plugin) in which the tests will be run during the integration-test phase and finally stop the server kind software in post-integration-test...(typical scenarios in web applications for selenium tests / jwebunit or arquillian tests)... What about those database tests. The setup you need to do is either clear the database setup the structure (DDL) and fill in those needed default data you need to run your tests (prerequisite for your test) (sql-maven-plugin for example)..So you need at least pre-integration-test phase...which is not bound to maven-failsafe-plugin... Furthermore if you think about other possibilies where you might for an batch application which you can start via exec-maven-pluginetc. etc. That's from my point of view the reason not to integrate into the default life-cyclebecause it's not a general practice nor a general solutionall other bindings are really general solutions which work for all java projects... An other point what about the check goal of maven-failsafe-plugin which is intended to fail the build in case of failed integration testsbut sometimes you don't like this... And an other point which comes into my mind. Usually integration tests are long runners which means if you like to make a release you would have to run them as well if the integration tests bound to the life cycle...if you have integration tests which runs hours you don't like to have them executed every time you would like to make release... If you wan't to try to prevent DRY the simple solution is to create a company (project parent) pom which contains such kind of configurations where you simply can bind maven-failsafe-plugin to the appropriate life cycle phases. Why do people stuck with maven-surefire-plugin? Simple answer: They don't know it. Often people don't understand that there is a subtle difference between unit and integration tests...in particular in relationship to the build you are running which gives you a better control over what exactly is running...by definition unit tests can be parallelized in contradiction integration tests can't. Based on this you see a difference in configuration for maven-surefire-plugin (multi threading) whereas you need to configure maven-failsafe-plugin different... Kind regards Karl Heinz Marbaise On 10/28/14 6:06 PM, Jeff Jensen wrote: Integrating Failsafe in the same way as Surefire would be great for a lot of people I think. I agree! Personally, I wonder why we don't merge them. I've wondered the same thing... is there a technical reason why it won't or is difficult to make work? On Tue, Oct 28, 2014 at 11:54 AM, Benson Margulies bimargul...@gmail.com wrote: Personally, I wonder why we don't merge them. Failsafe adds some lifestyle phase bindings and then changes some defaults. Otherwise, it's a giant anti-DRY. Why not expand surefire to have the extra executions with shifted defaults for things like test class names? On Tue, Oct 28, 2014 at 11:50 AM, Oliver B. Fischer mails...@swe-blog.net wrote: @Paul: Yes I think so or we find a way more convenient in this moment. @all: I think this shows perfectly why Failsafe should be integrated as Surefire already is. Oliver Am 28.10.14 16:02, schrieb Paul Benedict: Thanks. Now I know when to use this. For my situation, which is integration testing against an existing database, I don't need to setup an environment; this explains why I never needed to use the plugin. There are other cases the plugin will be valuable, but I wonder if this is why most others stick with surefire. I guess programmers don't scratch unless there's an itch. Cheers, Paul On Tue, Oct 28, 2014 at 9:21 AM, Anders Hammar and...@hammar.net wrote: The answer is on the index page of the failsafe plugin [1]. If you use the Surefire Plugin for running tests... /Anders [1] http://maven.apache.org/surefire/maven-failsafe-plugin/ On Tue, Oct 28, 2014 at 3:18 PM, Paul Benedict pbened...@apache.org wrote: (to mails...@swe-blog.net https://bitbucket.org/obfischer/bugreport-maven-failsafe.git lot - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Archiver version 2.6
Hi, On 10/28/14 8:57 PM, Michael Osipov wrote: Am 2014-10-28 um 20:31 schrieb Karl Heinz Marbaise: Hi, checked SHA1 Ok.. tested with Maven 2.2.1, 3.0.5, 3.1.1, 3.2.1, 3.2.2, 3.2.3 no issues found. So +1 from me... Unfortunately the number of checkstyle errors has increased from 29 in version 2.5 to 39 in version 2.6...created an appropriate jira for it http://jira.codehaus.org/browse/MSHARED-380 I'll have a look after the release. Why below 29? Is that a magic number? That's the number of errors in maven-archiver version 2.5 so it should in my opinion less than 29 to have an improvement...;-)... Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Proposal: Ease the usage of Failsafe
2014-10-28 17:54 GMT+01:00 Benson Margulies bimargul...@gmail.com: Personally, I wonder why we don't merge them. Failsafe adds some lifestyle phase bindings and then changes some defaults. Otherwise, it's a giant anti-DRY. Why not expand surefire to have the extra executions with shifted defaults for things like test class names? As Surefire and Failsafe are practically the same with only differences in their lifecycle binding, default values for some of the configuration parameters and distinct properties for the parameters (e.g. -Dtest=.. vs. -Dit.test=...), there wouldn't be much to merge. Both are rather slim specializations of the same abstract mojo implementation. I can't think of something that you can't technically do with the one mojo that you can do with the other. Merging them would just make it harder to configure the different executions for the different phases. It's just depending on the use case, which of them is already out-of-the-box configured to match the requirements - or is at least close to it. On Tue, Oct 28, 2014 at 11:50 AM, Oliver B. Fischer mails...@swe-blog.net wrote: @Paul: Yes I think so or we find a way more convenient in this moment. @all: I think this shows perfectly why Failsafe should be integrated as Surefire already is. Oliver Am 28.10.14 16:02, schrieb Paul Benedict: Thanks. Now I know when to use this. For my situation, which is integration testing against an existing database, I don't need to setup an environment; this explains why I never needed to use the plugin. There are other cases the plugin will be valuable, but I wonder if this is why most others stick with surefire. I guess programmers don't scratch unless there's an itch. Cheers, Paul On Tue, Oct 28, 2014 at 9:21 AM, Anders Hammar and...@hammar.net wrote: The answer is on the index page of the failsafe plugin [1]. If you use the Surefire Plugin for running tests... /Anders [1] http://maven.apache.org/surefire/maven-failsafe-plugin/ On Tue, Oct 28, 2014 at 3:18 PM, Paul Benedict pbened...@apache.org wrote: (to mails...@swe-blog.net https://bitbucket.org/obfischer/bugreport-maven-failsafe.git lot - 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: [ANN] Apache Maven Assembly Plugin 2.5 Released
Unfortunately filtering into tar/zip is broken (http://jira.codehaus.org/browse/MASSEMBLY-722), and users of filtering/line endings must use a previous version or wait for 2.5.1, which will be released fairly soon. Kristian 2014-10-27 5:50 GMT+01:00 Kristian Rosenvold kristian.rosenv...@zenior.no: The Apache Maven team is pleased to announce the release of the long-awaited Apache Maven Assembly Plugin, version 2.5. The Assembly Plugin for Maven is primarily intended to allow users to aggregate the project output along with its dependencies, modules, site documentation, and other files into a single distributable archive. Notable in this release is improved file attribute support and full symlink support for java7+ users. Users of filtering/line ending selection should also notice a nice performance improvement. A large number of bugs have also been fixed. http://maven.apache.org/plugins/maven-assembly-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-assembly-plugin/artifactId version2.5/version /plugin Release Notes - Maven Assembly Plugin - Version 2.5 ** Bug * [MASSEMBLY-75] - Unpacked TAR dependencies do not preserve file mode nor uid/gid * [MASSEMBLY-458] - Directory name resolution ignores $ and beyond * [MASSEMBLY-495] - Assembly changes timestamps when extracting dependency sets * [MASSEMBLY-523] - Filtering causes a loss of original unix file permissions * [MASSEMBLY-543] - japanese filenames cannot be correctly assembled by maven-assembly-plugin * [MASSEMBLY-557] - Corrupted zip created by assembly: extracting the zip forgets certain folders (or throws permission denied errors) possibly because zip index is corrupted * [MASSEMBLY-563] - JAR entry not found when including jar dependencies with # in classname * [MASSEMBLY-576] - addClasspath broken in new single goal * [MASSEMBLY-605] - Filtering does not work on files which are symlinks * [MASSEMBLY-615] - assembly:single fails with odd resource file name * [MASSEMBLY-622] - Unable to create TAR artifacts * [MASSEMBLY-641] - Assembly fails on resource name with a percent character * [MASSEMBLY-661] - Assembly plugin looses permissions when using fileSets * [MASSEMBLY-670] - Specifying lineEnding option of fileSet causes timestamps not to be preserved * [MASSEMBLY-684] - Parallel Execution w Custom Assembly Descriptor Fails * [MASSEMBLY-692] - Assembly ID is global * [MASSEMBLY-709] - When assembling a zip on windows duplicate files are added to the assembly * [MASSEMBLY-721] - Failing ITs for Maven 2.2.1 ** Improvement * [MASSEMBLY-479] - Add option to generate Posix tar files. * [MASSEMBLY-530] - Allow configuration of encoding * [MASSEMBLY-638] - [PATCH] Support tgz and tbz2 formats in assemblies * [MASSEMBLY-673] - Add support for delimiters and useDefaultDelimiters like the maven-resources-plugin 2.4 has * [MASSEMBLY-688] - Use maven-invoker-plugin 1.9 * [MASSEMBLY-705] - Removed compatibility with Maven 2.0.X * [MASSEMBLY-706] - MavenProject/MavenSession Injection as a paremeter instead as a component. * [MASSEMBLY-707] - Remove unnecessary excludes / Cleaning up console output * [MASSEMBLY-710] - Fix RAT Report * [MASSEMBLY-712] - Update version of plexus-archiver to 2.5 * [MASSEMBLY-714] - Update version of plexus-archiver to 2.7.1 * [MASSEMBLY-716] - Update plexus-io from 2.0.9 to 2.3.2 * [MASSEMBLY-719] - Ugrade to plexus-interpolation 1.21 ** New Feature * [MASSEMBLY-717] - Add an option to turn off project filters ** Wish * [MASSEMBLY-343] - add symbolic links managment (java7+ only supported) Enjoy, -The Apache Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Archiver version 2.6
+1 2014-10-26 22:06 GMT+01:00 Michael Osipov micha...@apache.org: Hi, We solved 9 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=18325projectId=11761 There are still a couple of issues left in JIRA: http://jira.codehaus.org/browse/MSHARED-168?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1086/ http://repository.apache.org/content/repositories/maven-1086/org/apache/maven/maven-archiver/2.6/maven-archiver-2.6-source-release.zip Source release checksum(s): maven-archiver-2.6-source-release.zip sha1: 1abc6527f6a3ce037db8c3bc549bb07876f4347a Staging site: http://maven.apache.org/shared-archives/maven-archiver-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - 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] Release Apache Maven Clean Plugin version 2.6.1
+1 (non binding), tested with my internal builds On Tue, Oct 28, 2014 at 12:33 PM, Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi, here my +1... Kind regards Karl Heinz Marbaise On 10/26/14 8:48 PM, Karl Heinz Marbaise wrote: Hi, We solved 6 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa? projectId=11128version=20685 There are still 2 issues left in JIRA: http://jira.codehaus.org/issues/?jql=project%20%3D% 20MCLEAN%20AND%20status%20%3D%20Open%20ORDER%20BY%20key% 20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1085 http://repository.apache.org/content/repositories/maven- 1085/org/apache/maven/plugins/maven-clean-plugin/2.6.1/ maven-clean-plugin-2.6.1-source-release.zip Source release checksum(s): maven-clean-plugin-source-release.zip sha1: ef240a899fe1e7425e96ece23d3d75c9ec268782 Staging site: http://maven.apache.org/plugins-archives/maven-clean-plugin-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] maven-surefire pull request: [SUREFIRE-1053] Suppress warning mess...
GitHub user Tibor17 opened a pull request: https://github.com/apache/maven-surefire/pull/63 [SUREFIRE-1053] Suppress warning message if file.encoding is set using argLine Fix for http://jira.codehaus.org/browse/SUREFIRE-1053 You can merge this pull request into a Git repository by running: $ git pull https://github.com/Tibor17/maven-surefire s4 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven-surefire/pull/63.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #63 commit b87adf91c91d9811d857dcab0c07658995a7b4ef Author: tibordigana tibo...@lycos.com Date: 2014-10-29T00:51:38Z [SUREFIRE-1053] Suppress warning message if file.encoding is set using argLine --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Clean Plugin version 2.6.1
+1 notice that the JDK requirement is Default target for maven-compiler-plugin version 3.1 [1]: I don't know what it means nor why we have such result (first time I see), but this is hard to understand Regards, Hervé [1] http://maven.apache.org/plugins-archives/maven-clean-plugin-LATEST/plugin-info.html Le dimanche 26 octobre 2014 20:48:28 Karl Heinz Marbaise a écrit : Hi, We solved 6 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11128version=206 85 There are still 2 issues left in JIRA: http://jira.codehaus.org/issues/?jql=project%20%3D%20MCLEAN%20AND%20status%2 0%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1085 http://repository.apache.org/content/repositories/maven-1085/org/apache/mave n/plugins/maven-clean-plugin/2.6.1/maven-clean-plugin-2.6.1-source-release.z ip Source release checksum(s): maven-clean-plugin-source-release.zip sha1: ef240a899fe1e7425e96ece23d3d75c9ec268782 Staging site: http://maven.apache.org/plugins-archives/maven-clean-plugin-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Kind regards Karl Heinz Marbaise - 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] Release Maven Archiver version 2.6
+1 Regards, Hervé Le dimanche 26 octobre 2014 22:06:40 Michael Osipov a écrit : Hi, We solved 9 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=18325projectId=117 61 There are still a couple of issues left in JIRA: http://jira.codehaus.org/browse/MSHARED-168?jql=project%20%3D%20MSHARED%20AN D%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1086/ http://repository.apache.org/content/repositories/maven-1086/org/apache/mave n/maven-archiver/2.6/maven-archiver-2.6-source-release.zip Source release checksum(s): maven-archiver-2.6-source-release.zip sha1: 1abc6527f6a3ce037db8c3bc549bb07876f4347a Staging site: http://maven.apache.org/shared-archives/maven-archiver-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - 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: Who evaluates menu ref=parent|modules / in site.xml?
see doxia-integration-tools DefaultSiteTool populateParentMenu(...) [1] and populateModulesMenu(...) [2] called by getDecorationModel(...) then getDecorationModel(...) is called from AbstractSiteRenderingMojo.createSiteRenderingContext(...) But looking at MPIR-279, I fear you're fighting against a non-bug, just some unexpected consequences of not using the standard directory layout from modules (ie directory = artifactId) without manually updating a serie of POM elements which are calculated with the convention Perhaps what can help is documenting what POM elements to be manually defined in case of non-standard module directory path: I never tried to do so, always fighting about what was told as a bug Regards, Hervé [1] http://maven.apache.org/doxia/doxia-tools/doxia-integration-tools/xref/org/apache/maven/doxia/tools/DefaultSiteTool.html#L638 [2] http://maven.apache.org/doxia/doxia-tools/doxia-integration-tools/xref/org/apache/maven/doxia/tools/DefaultSiteTool.html#L733 Le mardi 28 octobre 2014 20:05:12 Michael Osipov a écrit : Hi, I'd like to fix MPIR-279 and by applying the logic from above. I am having a hard time to find that spot which actually evalutes the snippet above. Does someone know? Thanks, Michael - 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] Release Apache Maven JXR version 2.5
Le lundi 27 octobre 2014 09:13:47 Karl Heinz Marbaise a écrit : Hi Michael, On 10/27/14 7:23 AM, Michael Osipov wrote: Am 2014-10-26 um 23:15 schrieb Karl Heinz Marbaise: Hi, We solved 10 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11085version= 19853 JXR-116: Doxia is already at 1.6. Shouldn't we upgrade first? Yes this is true, but the consequence is that the code has to be changed...which took...who knows how long...first i would get a release out of the door... I recently saw I missed to upgrade Doxia when releasing maven-reporting-impl 2.3, then because of DOXIA-499, a reporting plugin can upgrade only to Doxia 1.4, or it will fail when used as Maven direct goal (instead of site report) this is fixed in MSHARED-344: needs a new release... Regards, Hervé - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[DISCUSS] removing Maven 3.1.1 from proposed downloads
we currently propose 3 versions: 3.0.5, 3.1.1 and 3.2.3 which suppose we may release 3.0.6, 3.1.2 and 3.2.4 in the future I see why we would release 3.0.6: Aether change force some users to stay to 3.0.x, and I started to define some backports I'd like to put in it [1] But I don't see why we would release 3.1.2: AFAIK, there is no outstanding change in 3.2.x that blocks 3.1.x users from upgrading to 3.2.x, isn't it? Then IMHO, we should remove 3.1.1 from top download links, and only propose 3.0.5 and 3.2.3 This wouldn't only make our roadmap easier to understand Any objection? Hervé [1] http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=20703 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven JXR version 2.5
+1 same strange Default target for maven-compiler-plugin version 3.1JDK requirement [1] as Maven Clean Plugin we'll probably have something to do to improve this, because it seems updated parent pom puts this for every plugin... Regards, Hervé [1] http://maven.apache.org/jxr-archives/jxr-LATEST/maven-jxr-plugin/plugin-info.html Le dimanche 26 octobre 2014 23:15:52 Karl Heinz Marbaise a écrit : Hi, We solved 10 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11085version=198 53 There are still a couple of issues left in JIRA: http://jira.codehaus.org/issues/?jql=project%20%3D%20JXR%20AND%20status%20%3 D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1087 http://repository.apache.org/content/repositories/maven-1087/org/apache/mave n/jxr/jxr/2.5/jxr-2.5-source-release.zip Source release checksum(s): jxr-source-release.zip sha1: a6b1658404b8d2362641b2a8279c545d13c9ef88 Staging site: http://maven.apache.org/jxr-archives/jxr-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Kind regards Karl Heinz Marbaise - 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: [DISCUSS] removing Maven 3.1.1 from proposed downloads
+1 to that. Good idea imho.. manfred Hervé BOUTEMY wrote on 28.10.2014 19:24: we currently propose 3 versions: 3.0.5, 3.1.1 and 3.2.3 which suppose we may release 3.0.6, 3.1.2 and 3.2.4 in the future I see why we would release 3.0.6: Aether change force some users to stay to 3.0.x, and I started to define some backports I'd like to put in it [1] But I don't see why we would release 3.1.2: AFAIK, there is no outstanding change in 3.2.x that blocks 3.1.x users from upgrading to 3.2.x, isn't it? Then IMHO, we should remove 3.1.1 from top download links, and only propose 3.0.5 and 3.2.3 This wouldn't only make our roadmap easier to understand Any objection? Hervé [1] http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=20703 - 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: [DISCUSS] removing Maven 3.1.1 from proposed downloads
+1 On Wed, Oct 29, 2014 at 10:22 AM, Manfred Moser manf...@mosabuam.com wrote: +1 to that. Good idea imho.. manfred Hervé BOUTEMY wrote on 28.10.2014 19:24: we currently propose 3 versions: 3.0.5, 3.1.1 and 3.2.3 which suppose we may release 3.0.6, 3.1.2 and 3.2.4 in the future I see why we would release 3.0.6: Aether change force some users to stay to 3.0.x, and I started to define some backports I'd like to put in it [1] But I don't see why we would release 3.1.2: AFAIK, there is no outstanding change in 3.2.x that blocks 3.1.x users from upgrading to 3.2.x, isn't it? Then IMHO, we should remove 3.1.1 from top download links, and only propose 3.0.5 and 3.2.3 This wouldn't only make our roadmap easier to understand Any objection? Hervé [1] http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=20703 - 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 -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier
Re: [DISCUSS] removing Maven 3.1.1 from proposed downloads
+1 (non-binding) Gary On Tue, Oct 28, 2014 at 10:24 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: we currently propose 3 versions: 3.0.5, 3.1.1 and 3.2.3 which suppose we may release 3.0.6, 3.1.2 and 3.2.4 in the future I see why we would release 3.0.6: Aether change force some users to stay to 3.0.x, and I started to define some backports I'd like to put in it [1] But I don't see why we would release 3.1.2: AFAIK, there is no outstanding change in 3.2.x that blocks 3.1.x users from upgrading to 3.2.x, isn't it? Then IMHO, we should remove 3.1.1 from top download links, and only propose 3.0.5 and 3.2.3 This wouldn't only make our roadmap easier to understand Any objection? Hervé [1] http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=20703 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [DISCUSS] removing Maven 3.1.1 from proposed downloads
+1 29. Okt. 2014 03:24 skrev Hervé BOUTEMY herve.bout...@free.fr følgende: we currently propose 3 versions: 3.0.5, 3.1.1 and 3.2.3 which suppose we may release 3.0.6, 3.1.2 and 3.2.4 in the future I see why we would release 3.0.6: Aether change force some users to stay to 3.0.x, and I started to define some backports I'd like to put in it [1] But I don't see why we would release 3.1.2: AFAIK, there is no outstanding change in 3.2.x that blocks 3.1.x users from upgrading to 3.2.x, isn't it? Then IMHO, we should remove 3.1.1 from top download links, and only propose 3.0.5 and 3.2.3 This wouldn't only make our roadmap easier to understand Any objection? Hervé [1] http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=20703 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
