[ANN] Maven Surefire Plugin 2.7 Released
he Maven team is pleased to announce the release of the Maven Surefire Plugin, version 2.7 This release includes the maven-surefire-plugin, which executes the unit tests of an application, the maven-surefire-report-plugin, which parses surefire/failsafe test results and renders them to DOXIA creating the web interface version of the test results, as well as the maven-failsafe-plugin, which executes the integration tests of an application. Highlights of this release: * Pluggable providers are now supported, as well as manual provider selection * 2.7 is significantly smaller and lighter than earlier 2.x versions (Only 30% of the download size) * A large chunk of the highest voted issues have been fixed. * Some performance optimizations for forkMode=always * Significant reduction in memory use and increase in performance for users who log console output to file. * Significant cleanup/simplification of the code-base Note to JUnit4 users upgrading: Due to SUREFIRE-482 upgrading to surefire 2.7 may cause some (incorrectly defined) tests to not be run any more. This should be verified by running mvn -Dsurefire.junit4.upgradecheck=true install at least once (this can be run multiple times until you have fixed all issues) http://maven.apache.org/plugins/maven-surefire-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.7/version /plugin Release Notes - Maven Surefire - Version 2.7 ** Bug * [SUREFIRE-482] - Surefire tries to run JUnit4 tests that contain no @Test annotations * [SUREFIRE-495] - OutOfMemory Exception * [SUREFIRE-501] - -Xmx JVM option is not used by the surefire process * [SUREFIRE-506] - Maven runs suite() methods of all junit 3.x tests for each unit test even when forkMode is set to always * [SUREFIRE-509] - NoClassDefFoundError: org/apache/maven/surefire/booter/SurefireBooter with Java 1.3 * [SUREFIRE-538] - Surefire-booter and surefire-integration-tests require 1.4 but fail to specify it in their POMs * [SUREFIRE-599] - Logs console output multiple times (no. of times log output = the no. of test being run) for JUnit/XMLUnit tests * [SUREFIRE-638] - Plugin cannot handle java in a path name * [SUREFIRE-639] - Error inside systemOut parser: java.lang.IllegalStateException: testSetStarting called twice * [SUREFIRE-640] - org.apache.maven.surefire.booter.shade.org.codehaus.plexus.util.cli.CommandLineException: Error inside systemErr parser * [SUREFIRE-642] - TestNG support doesn't w/o Junit on classpath * [SUREFIRE-653] - java.lang.NoClassDefFoundError: org/apache/maven/surefire/booter/SurefireBooter when use toolchains with jdk 1.3 * [SUREFIRE-657] - Surefire silently fails when argLine contains tabs or newlines * [SUREFIRE-660] - Using testng with testng 5.14.2 add a dependency com.google.inject:guice which cannot be overriden * [SUREFIRE-665] - Output to file stops after a while ** Improvement * [SUREFIRE-321] - Run tests in alphabetical order * [SUREFIRE-408] - add capability to turn on only a specific provider * [SUREFIRE-573] - When temp directory is missing or not writeable, error messages should state that plainly somewhere * [SUREFIRE-614] - Run tests in random order * [SUREFIRE-652] - Store surefire tmp files under target/ instead of java.io.tmpdir * [SUREFIRE-658] - Excessive synchronization in ReporterManager blocks performance * [SUREFIRE-662] - Forkmode=always rescans classpath in every forked vm * [SUREFIRE-664] - Parallel surefire reporter does not report real execution times ** New Feature * [SUREFIRE-141] - Surefire should provide a pluggable means to specify a custom provider * [SUREFIRE-661] - Add ConfigurableParallelComputer to junit core provider * [SUREFIRE-663] - Allow custom Junit4 RunListeners to be specified ** Task * [SUREFIRE-292] - Documentation for surefire API and providers Enjoy, -The Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [RESULT] [VOTE] Release Maven Surefire Plugin version 2.7, Take 2
Mark, I now have a second report of this and a test-project (via twitter ;). I will track the problem from there. I have been planning to do a 2.7.1 maintenance release in 2-4 weeks time, so whatever it is will be fixed for 2.7.1 Kristian Looks like I had a rogue debugger process left around, the mockito issue is still haunting me tho. This is on a line doing: doReturn(something).when(spiedObject).doSomething(); - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [RESULT] [VOTE] Release Maven Surefire Plugin version 2.7, Take 2
Hi, Sorry for not taking the time to test this while the vote was in progress. However, I think I've found a regression causing the failsafe plugin v2.7 to report builds with broken integration tests as successful. I've created [1] already - hope I got my reasoning correct in the description. Just wanted to give you a heads up on the list as well if you're looking for candidates to go into an upcoming maintenance release. This is obviously blocking us from upgrading but it appears 2.6 still works fine for us so I'll put that back in the build for the time being. [1] http://jira.codehaus.org/browse/SUREFIRE-672 -- - Jan Fredrik Wedén On Tue, Dec 21, 2010 at 13:03, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Mark, I now have a second report of this and a test-project (via twitter ;). I will track the problem from there. I have been planning to do a 2.7.1 maintenance release in 2-4 weeks time, so whatever it is will be fixed for 2.7.1 Kristian Looks like I had a rogue debugger process left around, the mockito issue is still haunting me tho. This is on a line doing: doReturn(something).when(spiedObject).doSomething(); - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [RESULT] [VOTE] Release Maven Surefire Plugin version 2.7, Take 2
It seems like this issue + the mockito problem (http://jira.codehaus.org/browse/SUREFIRE-673) will make 2.7.1 happen sooner rather than later. Sticking to your previous favourite version is always an option. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Project Info Reports Plugin version 2.3.1
The vote has passed with the following result : +1 (binding): Hervé Boutemy, Lukas Theussl, Olivier Lamy, Benjamin Bentmann, Vincent Siveton I will promote the artifacts to the central repo. 2010/12/18 Vincent Siveton vsive...@apache.org: Hi, This is a maintenance release. We solved 5 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11142version=17021 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11142status=1 Staging repo: https://repository.apache.org/content/repositories/maven-034/ Staging site: http://maven.apache.org/plugins/maven-project-info-reports-plugin-2.3.1 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
feedback on maven-invoker-plugin patches
Hi, I created two issues for maven-invoker-plugin: duplicate script classpath entries are not filtered out, can cause ClassCastException - http://jira.codehaus.org/browse/MINVOKER-112 and update to Groovy 1.7.5 (from 1.5.6) - http://jira.codehaus.org/browse/MINVOKER-113 The first issue is a bug and the second is an improvement. I've attached some clean, straight-forward patches to each. Any feedback is appreciated. I'm hoping those can get applied soon. Also, if there's interest, I can contribute some time to get the project Java 5'd (adding generics, enhanced for loops, etc.). Thanks, Luke -- View this message in context: http://maven.40175.n5.nabble.com/feedback-on-maven-invoker-plugin-patches-tp3313521p3313521.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[ANN] Maven Project Info Reports Plugin 2.3.1 Released
The Maven team is pleased to announce the release of the Maven Project Info Reports Plugin, version 2.3.1 This plugin is used to generate reports information about the project. http://maven.apache.org/plugins/maven-project-info-reports-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-project-info-reports-plugin/artifactId version2.3.1/version /plugin Release Notes - Maven 2.x Project Info Reports Plugin - Version 2.3.1 ** Bug * [MPIR-201] - The project info module report produces incorrect links * [MPIR-209] - Wrong links in modules overview page if module artifactId does not match directory structure * [MPIR-210] - Project Summary Download link points to distributionManagement (upload) url * [MPIR-211] - NPE with custom text bundle * [MPIR-212] - src/main/java does not exist for non-jar project Enjoy, -The Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: feedback on maven-invoker-plugin patches
Hello, I will have a look. 2010/12/21 lukewpatterson lukewpatter...@gmail.com: Hi, I created two issues for maven-invoker-plugin: duplicate script classpath entries are not filtered out, can cause ClassCastException - http://jira.codehaus.org/browse/MINVOKER-112 and update to Groovy 1.7.5 (from 1.5.6) - http://jira.codehaus.org/browse/MINVOKER-113 The first issue is a bug and the second is an improvement. I've attached some clean, straight-forward patches to each. Any feedback is appreciated. I'm hoping those can get applied soon. Also, if there's interest, I can contribute some time to get the project Java 5'd (adding generics, enhanced for loops, etc.). Thanks, Luke -- View this message in context: http://maven.40175.n5.nabble.com/feedback-on-maven-invoker-plugin-patches-tp3313521p3313521.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy http://twitter.com/olamy http://www.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] Establish a creation and retirement plan for plugins
On 2010-12-16 11:44, Nord, James wrote: +0 (non-binding) One comment I would make is if the plugin moves to another forge (hence different groupId) a relocation pom should be created at the old location - not just an update to the SCM. This would mean that we (the Maven project) would have to deploy relocation POMs everytime the new plugin owner makes a release. Unfortunately relocation POMs are much harder to use than first meets the eye. /James -Original Message- From: Dennis Lundberg [mailto:denn...@apache.org] Sent: 15 December 2010 21:52 To: Maven Developers List Subject: [VOTE] Establish a creation and retirement plan for plugins Hi No one objected to the proposal I made on November 1. Jason and I have polished the proposal based on the comments that were made. The final (?) version can be found here: https://cwiki.apache.org/confluence/display/MAVEN/Proposal+--+A+creation+and+retirement+plan+for+plugins Please vote on whether we should make this proposal our policy. [ ] +1 Let's use it [ ] -1 No way If the vote succeeds I'll put it on the Maven site somewhere. Suggestions on where to put are welcome. -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org ** This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmas...@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary. NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00 ** - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Establish a creation and retirement plan for plugins
I've done most of the requested changes on the wiki: * Clarify that reitrement must be announced on the plugin's site * Add apache-extras.org as a possible forge * Remove creation of new plugins from the plan * We can't change the SCM URL for the final release, so we fix the reports on the site instead. These suggestions I did not put on the wiki, see my replies to the thread for my reasons: * Make the final release preferred but optional * If the plugin moves to another forge a relocation pom should be created If there are no more feedback I'll take the wiki content and put it somewhere under http://maven.apache.org/developers/ On 2010-12-15 22:52, Dennis Lundberg wrote: Hi No one objected to the proposal I made on November 1. Jason and I have polished the proposal based on the comments that were made. The final (?) version can be found here: https://cwiki.apache.org/confluence/display/MAVEN/Proposal+--+A+creation+and+retirement+plan+for+plugins Please vote on whether we should make this proposal our policy. [ ] +1 Let's use it [ ] -1 No way If the vote succeeds I'll put it on the Maven site somewhere. Suggestions on where to put are welcome. -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Establish a creation and retirement plan for plugins
Dennis Lundberg wrote: One comment I would make is if the plugin moves to another forge (hence different groupId) a relocation pom should be created at the old location - not just an update to the SCM. This would mean that we (the Maven project) would have to deploy relocation POMs everytime the new plugin owner makes a release. Unfortunately relocation POMs are much harder to use than first meets the eye. Just reminds of http://jira.codehaus.org/browse/MNG-3762 Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Move Maven Changes Plugin to Java 5
+1 On 2010-12-15 20:25, Dennis Lundberg wrote: Hi I have some features I'd like to work on for the Changes Plugin. To simplify the work I would like to start using Java 5 features, such as generics for collections. The last release was version 2.3 and after that no issues have been fixed, so I don't see a reason to make a last Java 1.4 release of the current trunk. [ ] +1 Go for it [ ] -1 Don't do it -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[RESULT] [VOTE] Move Maven Changes Plugin to Java 5
Hello, The vote has passed with the following result: +1 (binding): Kristian Rosenvold, Benjamin Bentmann, Olivier Lamy, Stephen Connolly, Lukas Theussl, Emmanuel Venisse, Dennis Lundberg +1 (non binding): Baptiste Mathus, Tony Chemit, Karl Heinz Marbaise I have added an issue in JIRA to track it: http://jira.codehaus.org/browse/MCHANGES-210 On 2010-12-15 20:25, Dennis Lundberg wrote: Hi I have some features I'd like to work on for the Changes Plugin. To simplify the work I would like to start using Java 5 features, such as generics for collections. The last release was version 2.3 and after that no issues have been fixed, so I don't see a reason to make a last Java 1.4 release of the current trunk. [ ] +1 Go for it [ ] -1 Don't do it -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Modello and Maven Changes Plugin woes
Hi I have been trying to upgrade Maven Changes Plugin to use a newer version of Modello Maven Plugin. Currently it uses version 1.0.1. When I upgrade to version 1.0.2 (or newer) I start getting all sorts of weird test failures that I don't know how to fix. The errors occur for action elements that have both content and sub elements, and also attributes. Especially for these two files: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-changes-plugin/src/test/unit/announce-changes.xml?view=markup http://svn.apache.org/viewvc/maven/plugins/trunk/maven-changes-plugin/src/test/unit/changes.xml?view=markup Steps to reproduce: 1. Check out the current trunk of maven-changes-plugin 2. Change the version of modello-maven-plugin to 1.0.2 (or newer) 3. Run 'mvn test' Any help on how to solve this would be appreciated. -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Generating release notes as part of release
Apache Commons has a policy (which is in alignment with http://incubator.apache.org/guides/releasemanagement.html#best-practice) to include release notes in the source distribution. I would like to generate the release notes using the changes plugin during release:prepare and have them committed so that they appear in the svn tag. Since they provide no value on trunk I would like to then delete them as part of the post processing when the versions in the poms are changed to the next snapshot release. Has anyone done this or can recommend a simple way to do it? Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Generating release notes as part of release
The next release of the release plugin will have the completionGoals parameter which you will want to hook in the remove of the release notes - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 22 Dec 2010 03:44, Ralph Goers ralph.go...@dslextreme.com wrote: Apache Commons has a policy (which is in alignment with http://incubator.apache.org/guides/releasemanagement.html#best-practice) to include release notes in the source distribution. I would like to generate the release notes using the changes plugin during release:prepare and have them committed so that they appear in the svn tag. Since they provide no value on trunk I would like to then delete them as part of the post processing when the versions in the poms are changed to the next snapshot release. Has anyone done this or can recommend a simple way to do it? Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Generating release notes as part of release
Ok, but I don't see a delete operation in the scm plugin. Any idea on how to do the removal without that? OTOH, my first instinct was to think that the release plugin should be able to generate the release notes on its own. Ralph On Dec 21, 2010, at 7:57 PM, Stephen Connolly wrote: The next release of the release plugin will have the completionGoals parameter which you will want to hook in the remove of the release notes - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 22 Dec 2010 03:44, Ralph Goers ralph.go...@dslextreme.com wrote: Apache Commons has a policy (which is in alignment with http://incubator.apache.org/guides/releasemanagement.html#best-practice) to include release notes in the source distribution. I would like to generate the release notes using the changes plugin during release:prepare and have them committed so that they appear in the svn tag. Since they provide no value on trunk I would like to then delete them as part of the post processing when the versions in the poms are changed to the next snapshot release. Has anyone done this or can recommend a simple way to do it? Ralph - 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: Generating release notes as part of release
The scm api supports both add and remove. I think you will need to add your own plugin though, as the preparation goals and completion goals do not provide a means to specify properties, and, more importantly, the property includes is shared with a number of plugins, so you really only want scm:add to be in its own fork of maven. If you write your own plugin, it can create and add the release notes using one goal and remove the release notes using an other goal without requiring properties to be set... Also looking at m-scm-p it would not be too difficult to use the scm api from your plugin - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 22 Dec 2010 04:14, Ralph Goers ralph.go...@dslextreme.com wrote:
