Re: [VOTE] Release Apache Maven Surefire Plugin version 2.18.1
Hi,
so checked SHA1, Tested with Maven 3.0.5, 3.1.1, 3.2.1 without any issue...
Unfortunately testing with Maven 2.2.1 i got some failures:
Caused by: org.apache.maven.it.VerificationException: Exit code was
non-zero: 1; command line and log =
/usr/share/java/apache-maven-2.2.1/bin/mvn -e --batch-mode
-Dmaven.repo.local=/Users/kama/Downloads/surefire-2.18.1/surefire-integration-tests/../surefire-setup-integration-tests/target/it-repo
org.apache.maven.plugins:maven-clean-plugin:clean
-Dsurefire.version=2.18.1 -DtestNgVersion=5.7 -DtestNgClassifier=jdk15
-DforkCount=2 -DreuseForks=true -T2
-DtestProperty=testValue_${surefire.threadNumber}_${surefire.forkNumber}
test
Unable to parse command line options: Unrecognized option: -T2
usage: mvn [options] [goal(s)] [phase(s)]
which i can understand (-T2) does not exist in Maven 2.X...
in spite of the above result i will vote with +1
cause Maven 2 is not really relevant anymore ...
Nevertheless we should check our CI servers to get them correctly
running...and identify the problem to get a reliable CI system...
Kind regards
Karl Heinz Marbaise
On 12/24/14 5:03 PM, tibo...@lycos.com wrote:
Hi,
We solved 13 issues:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541version=20814
There are still a couple of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truemode=hidejqlQuery=project+%3D+SUREFIRE+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC
Staging repo:
https://repository.apache.org/content/repositories/maven-1110
https://repository.apache.org/service/local/repositories/maven-1110/content/org/apache/maven/surefire/surefire/2.18.1/surefire-2.18.1-source-release.zip
Source release checksum(s):
surefire-2.18.1-source-release.zip sha1:
59a04c54118e796ca3729b0376a71891d299ed9b
Staging site:
http://maven.apache.org/surefire-archives/surefire-LATEST/maven-surefire-plugin/index.html
http://maven.apache.org/surefire-archives/surefire-LATEST/maven-failsafe-plugin/index.html
http://maven.apache.org/surefire-archives/surefire-LATEST/maven-surefire-report-plugin/index.html
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: Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
It appears that IBM JDK6 is EOL september next year. People move at different speeds :) Kristian 2014-12-25 6:25 GMT+01:00 Gary Gregory garydgreg...@gmail.com: +1 Gary div Original message /divdivFrom: Benson Margulies bimargul...@gmail.com /divdivDate:12/24/2014 17:08 (GMT-05:00) /divdivTo: Maven Developers List dev@maven.apache.org /divdivCc: /divdivSubject: Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...) /divdiv /divHere's what I don't understand. I can see why people need to keep building apps that run on antediluvian version. I can't see why it's such a problem for a tool, such as Maven, to require 1.7. Who are we accomodating by the current policy, or even the 1.6 plan? Meanwhile, it seems to me that we don't need a complex system of releases. There will be no new 3.0.x releases except for some sort of exceptional event. If we simply open up everything except the 3.0.x branch of the core to 1.6 or 1.7, then the worst that happens is, in the event of a security issue out in a component or a plugin, someone has to make a branch from the last 1.5-compatible release to make the fix. On Wed, Dec 24, 2014 at 5:02 PM, Milos Kleint mkle...@gmail.com wrote: +1. jdk 1.6 is EOL-ed for some time (Feb 2013) already and even 1.7 will be EOL-ed in April 2015.. I would suggest moving straight to 1.7 but I guess that's been already discussed. Milos On Thu, Dec 25, 2014 at 7:54 AM, Robert Scholte rfscho...@apache.org wrote: +1, would also make testing with JDK9 easier, although I've already found a good solution for that. Robert Op Wed, 24 Dec 2014 14:20:06 +0100 schreef Kristian Rosenvold krosenv...@apache.org: Oops. Snappy contains 1.6 java bytecode, which breaks the build on maven plugins. We need to upgrade to 1.6; I'm taking this to the mailing list :) Last time discussed this we established a consensus to establish 3.0.5 (maybe 3.0.6) as a minimum baseline for the 3.x range of plugins. This 3.0.X has a 1.5 java requirement. The problem is that *everyone* is moving to 1.6 and it's getting increasingly hard to maintain a 1.5 code base. As an example, I have been moving code to apache commons, but we're basically unable to use this effort because commons is now 1.6. alternately I need to backport the code in a source-level-shading, but these things are getting silly. I propose the following: Make the 3.x line of plugins java 1.6+ only. Release all shared utilities in 1.6 versions in the 3.x version range. 3.0.X maven versions stay forever on the 2.x line of plugins and jdk 1.5. The most recent core version moves defaults to the 3.x range of plugins. The parent poms migrate to 3.x range some time in the near future. Keeping 3.0.x fixes to a minuimum (and critical stuff) only, will ensure that we can still stay 1.5 compatible here. Kristian 2014-12-24 13:52 GMT+01:00 Benson Margulies bimargul...@gmail.com: I don't have access to push a plexus-archiver release, could you please do the honors. Also, looks like my splitting job left some work behind in terms of the parent pom. - 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: Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
... and when I say CodeHaus above, I mean Apache. Fair? ;) 2014-12-25 13:11 GMT+01:00 Lennart Jörelid lennart.jore...@gmail.com: Quite true. :) But this opens another interesting discussion. Do we move the codehaus products with the slowest of the major JDK release cycles (i.e. to match the IBM JDK release cycle in this case)? Or with the Oracle JDK's release cycles? There may not be much difference in the mechanics of JDK 6 and JDK 7 - but there are certainly differences between JDK 8 and JDK 9, which we have to cater for (or at least create a strategy to handle). If so - do we aim for introducing module mechanics to match Oracle's JDK 9 release or the eventual IBM JDK's release? Or something else entirely? 2014-12-25 12:46 GMT+01:00 Kristian Rosenvold kristian.rosenv...@gmail.com: It appears that IBM JDK6 is EOL september next year. People move at different speeds :) Kristian 2014-12-25 6:25 GMT+01:00 Gary Gregory garydgreg...@gmail.com: +1 Gary div Original message /divdivFrom: Benson Margulies bimargul...@gmail.com /divdivDate:12/24/2014 17:08 (GMT-05:00) /divdivTo: Maven Developers List dev@maven.apache.org /divdivCc: /divdivSubject: Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...) /divdiv /divHere's what I don't understand. I can see why people need to keep building apps that run on antediluvian version. I can't see why it's such a problem for a tool, such as Maven, to require 1.7. Who are we accomodating by the current policy, or even the 1.6 plan? Meanwhile, it seems to me that we don't need a complex system of releases. There will be no new 3.0.x releases except for some sort of exceptional event. If we simply open up everything except the 3.0.x branch of the core to 1.6 or 1.7, then the worst that happens is, in the event of a security issue out in a component or a plugin, someone has to make a branch from the last 1.5-compatible release to make the fix. On Wed, Dec 24, 2014 at 5:02 PM, Milos Kleint mkle...@gmail.com wrote: +1. jdk 1.6 is EOL-ed for some time (Feb 2013) already and even 1.7 will be EOL-ed in April 2015.. I would suggest moving straight to 1.7 but I guess that's been already discussed. Milos On Thu, Dec 25, 2014 at 7:54 AM, Robert Scholte rfscho...@apache.org wrote: +1, would also make testing with JDK9 easier, although I've already found a good solution for that. Robert Op Wed, 24 Dec 2014 14:20:06 +0100 schreef Kristian Rosenvold krosenv...@apache.org: Oops. Snappy contains 1.6 java bytecode, which breaks the build on maven plugins. We need to upgrade to 1.6; I'm taking this to the mailing list :) Last time discussed this we established a consensus to establish 3.0.5 (maybe 3.0.6) as a minimum baseline for the 3.x range of plugins. This 3.0.X has a 1.5 java requirement. The problem is that *everyone* is moving to 1.6 and it's getting increasingly hard to maintain a 1.5 code base. As an example, I have been moving code to apache commons, but we're basically unable to use this effort because commons is now 1.6. alternately I need to backport the code in a source-level-shading, but these things are getting silly. I propose the following: Make the 3.x line of plugins java 1.6+ only. Release all shared utilities in 1.6 versions in the 3.x version range. 3.0.X maven versions stay forever on the 2.x line of plugins and jdk 1.5. The most recent core version moves defaults to the 3.x range of plugins. The parent poms migrate to 3.x range some time in the near future. Keeping 3.0.x fixes to a minuimum (and critical stuff) only, will ensure that we can still stay 1.5 compatible here. Kristian 2014-12-24 13:52 GMT+01:00 Benson Margulies bimargul...@gmail.com: I don't have access to push a plexus-archiver release, could you please do the honors. Also, looks like my splitting job left some work behind in terms of the parent pom. - 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 -- -- +==+ | Bästa hälsningar, | [sw. Best regards] | | Lennart Jörelid | EAI Architect Integrator |
Re: Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
Quite true. :) But this opens another interesting discussion. Do we move the codehaus products with the slowest of the major JDK release cycles (i.e. to match the IBM JDK release cycle in this case)? Or with the Oracle JDK's release cycles? There may not be much difference in the mechanics of JDK 6 and JDK 7 - but there are certainly differences between JDK 8 and JDK 9, which we have to cater for (or at least create a strategy to handle). If so - do we aim for introducing module mechanics to match Oracle's JDK 9 release or the eventual IBM JDK's release? Or something else entirely? 2014-12-25 12:46 GMT+01:00 Kristian Rosenvold kristian.rosenv...@gmail.com : It appears that IBM JDK6 is EOL september next year. People move at different speeds :) Kristian 2014-12-25 6:25 GMT+01:00 Gary Gregory garydgreg...@gmail.com: +1 Gary div Original message /divdivFrom: Benson Margulies bimargul...@gmail.com /divdivDate:12/24/2014 17:08 (GMT-05:00) /divdivTo: Maven Developers List dev@maven.apache.org /divdivCc: /divdivSubject: Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...) /divdiv /divHere's what I don't understand. I can see why people need to keep building apps that run on antediluvian version. I can't see why it's such a problem for a tool, such as Maven, to require 1.7. Who are we accomodating by the current policy, or even the 1.6 plan? Meanwhile, it seems to me that we don't need a complex system of releases. There will be no new 3.0.x releases except for some sort of exceptional event. If we simply open up everything except the 3.0.x branch of the core to 1.6 or 1.7, then the worst that happens is, in the event of a security issue out in a component or a plugin, someone has to make a branch from the last 1.5-compatible release to make the fix. On Wed, Dec 24, 2014 at 5:02 PM, Milos Kleint mkle...@gmail.com wrote: +1. jdk 1.6 is EOL-ed for some time (Feb 2013) already and even 1.7 will be EOL-ed in April 2015.. I would suggest moving straight to 1.7 but I guess that's been already discussed. Milos On Thu, Dec 25, 2014 at 7:54 AM, Robert Scholte rfscho...@apache.org wrote: +1, would also make testing with JDK9 easier, although I've already found a good solution for that. Robert Op Wed, 24 Dec 2014 14:20:06 +0100 schreef Kristian Rosenvold krosenv...@apache.org: Oops. Snappy contains 1.6 java bytecode, which breaks the build on maven plugins. We need to upgrade to 1.6; I'm taking this to the mailing list :) Last time discussed this we established a consensus to establish 3.0.5 (maybe 3.0.6) as a minimum baseline for the 3.x range of plugins. This 3.0.X has a 1.5 java requirement. The problem is that *everyone* is moving to 1.6 and it's getting increasingly hard to maintain a 1.5 code base. As an example, I have been moving code to apache commons, but we're basically unable to use this effort because commons is now 1.6. alternately I need to backport the code in a source-level-shading, but these things are getting silly. I propose the following: Make the 3.x line of plugins java 1.6+ only. Release all shared utilities in 1.6 versions in the 3.x version range. 3.0.X maven versions stay forever on the 2.x line of plugins and jdk 1.5. The most recent core version moves defaults to the 3.x range of plugins. The parent poms migrate to 3.x range some time in the near future. Keeping 3.0.x fixes to a minuimum (and critical stuff) only, will ensure that we can still stay 1.5 compatible here. Kristian 2014-12-24 13:52 GMT+01:00 Benson Margulies bimargul...@gmail.com: I don't have access to push a plexus-archiver release, could you please do the honors. Also, looks like my splitting job left some work behind in terms of the parent pom. - 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 -- -- +==+ | Bästa hälsningar, | [sw. Best regards] | | Lennart Jörelid | EAI Architect Integrator | | jGuru Europe AB | Mölnlycke - Kista | | Email: l...@jguru.se | URL: www.jguru.se | Phone | (skype):jgurueurope | (intl): +46 708 507 603 |
Re: [VOTE] Release Apache Maven Surefire Plugin version 2.18.1
Karl, my goal is to make happy user after 2.18. As I said this release is a legal fix for the blocker appeared in 2.18. The issue appeared 25-50% of plugin's lifetime. Pls see my comments SUREFIRE-1128. If you guys find more issues, feel free to post comments in JIRA. I am going to push the first code fixes in 2.19-SNAPSHOT related to SUREFIRE-1128. I can fix everything in code since i have the rights there, but other issues like memory settings and Reports directory is missing seems to be related to VM settings and there i don't have right to fix as it seems. - BR, tibor17 -- View this message in context: http://maven.40175.n5.nabble.com/VOTE-Release-Apache-Maven-Surefire-Plugin-version-2-18-1-tp5820843p5820965.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
Re: Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
+1 for moving to at least 1.6 or even 1.7. While 1.8 would be the release with more interesting features, I think requiring this would be too early. Regards Mirko -- Sent from my mobile On Dec 25, 2014 1:12 PM, Lennart Jörelid lennart.jore...@gmail.com wrote: Quite true. :) But this opens another interesting discussion. Do we move the codehaus products with the slowest of the major JDK release cycles (i.e. to match the IBM JDK release cycle in this case)? Or with the Oracle JDK's release cycles? There may not be much difference in the mechanics of JDK 6 and JDK 7 - but there are certainly differences between JDK 8 and JDK 9, which we have to cater for (or at least create a strategy to handle). If so - do we aim for introducing module mechanics to match Oracle's JDK 9 release or the eventual IBM JDK's release? Or something else entirely? 2014-12-25 12:46 GMT+01:00 Kristian Rosenvold kristian.rosenv...@gmail.com : It appears that IBM JDK6 is EOL september next year. People move at different speeds :) Kristian 2014-12-25 6:25 GMT+01:00 Gary Gregory garydgreg...@gmail.com: +1 Gary div Original message /divdivFrom: Benson Margulies bimargul...@gmail.com /divdivDate:12/24/2014 17:08 (GMT-05:00) /divdivTo: Maven Developers List dev@maven.apache.org /divdivCc: /divdivSubject: Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...) /divdiv /divHere's what I don't understand. I can see why people need to keep building apps that run on antediluvian version. I can't see why it's such a problem for a tool, such as Maven, to require 1.7. Who are we accomodating by the current policy, or even the 1.6 plan? Meanwhile, it seems to me that we don't need a complex system of releases. There will be no new 3.0.x releases except for some sort of exceptional event. If we simply open up everything except the 3.0.x branch of the core to 1.6 or 1.7, then the worst that happens is, in the event of a security issue out in a component or a plugin, someone has to make a branch from the last 1.5-compatible release to make the fix. On Wed, Dec 24, 2014 at 5:02 PM, Milos Kleint mkle...@gmail.com wrote: +1. jdk 1.6 is EOL-ed for some time (Feb 2013) already and even 1.7 will be EOL-ed in April 2015.. I would suggest moving straight to 1.7 but I guess that's been already discussed. Milos On Thu, Dec 25, 2014 at 7:54 AM, Robert Scholte rfscho...@apache.org wrote: +1, would also make testing with JDK9 easier, although I've already found a good solution for that. Robert Op Wed, 24 Dec 2014 14:20:06 +0100 schreef Kristian Rosenvold krosenv...@apache.org: Oops. Snappy contains 1.6 java bytecode, which breaks the build on maven plugins. We need to upgrade to 1.6; I'm taking this to the mailing list :) Last time discussed this we established a consensus to establish 3.0.5 (maybe 3.0.6) as a minimum baseline for the 3.x range of plugins. This 3.0.X has a 1.5 java requirement. The problem is that *everyone* is moving to 1.6 and it's getting increasingly hard to maintain a 1.5 code base. As an example, I have been moving code to apache commons, but we're basically unable to use this effort because commons is now 1.6. alternately I need to backport the code in a source-level-shading, but these things are getting silly. I propose the following: Make the 3.x line of plugins java 1.6+ only. Release all shared utilities in 1.6 versions in the 3.x version range. 3.0.X maven versions stay forever on the 2.x line of plugins and jdk 1.5. The most recent core version moves defaults to the 3.x range of plugins. The parent poms migrate to 3.x range some time in the near future. Keeping 3.0.x fixes to a minuimum (and critical stuff) only, will ensure that we can still stay 1.5 compatible here. Kristian 2014-12-24 13:52 GMT+01:00 Benson Margulies bimargul...@gmail.com : I don't have access to push a plexus-archiver release, could you please do the honors. Also, looks like my splitting job left some work behind in terms of the parent pom. - 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
Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
Hi, let me summarize things a little bit: Last time discussed this we established a consensus to establish 3.0.5 (maybe 3.0.6) as a minimum baseline for the 3.x range of plugins. http://www.mail-archive.com/dev@maven.apache.org/msg102539.html that was not three months ago...so the line to lift all plugins to 2.2.1 minimum is not very far way... I would assume a month or two...I hope less.. https://builds.apache.org/job/dist-tool-plugin/site/dist-tool-prerequisites.html maven-enforcer: next takes a little bit..working on it... maven-ear-plugin: waiting for a feedback (on monday i hope so). After that i will call a VOTE for it... maven-jar-plugin: currently one issue open. maven-gpg-plugin: could be released... maven-plugin-plugin: currently no issue open for the 3.4 release (so could be pushed out in very short time) maven-compiler-plugin: just to fit 2.2.1 could be released maven-antrun-plugin: Release 1.8 prepared (i would call a vote in a few days). maven-jarsigner-plugin: Could be released...to fullfil 2.2.1 maven-archetype-plugin: Takes some time...started to work on it So now the problematic items: maven-ant-plugin: Should be retired maven-doap-plugin: Might be retired maven-stage-plugin: Might be retired maven-docck-plugin: Might be retired Unsure maven-patch-plugin: Should be retired (better use VCS for such things). maven-repository-plugin: Might be retired maven-verifier-plugin: Should be retired maven-eclipse-plugin: Should be retired to bring people to correct direction and use m2e instead So now coming to the maven releases: Maven 3.0.X line No change for a year (https://github.com/apache/maven/tree/maven-3.0.x) No issue related to 3.0.X line in JIRA Maven 3.1.X Line No change for 10 months (https://github.com/apache/maven/tree/maven-3.1.x) No issue related to 3.1.X line in JIRA So next level upgrading will be 3.0.5 minium So we should declare EoL for Maven 3.0.5 in Februar 2015...or earlier... and for 3.1.1 in April... So based on the above i would say moving to Java 1.6 does really make sense although it is inconsistent from the user point of view...but making a clear release note shouldn't be that hard to make... So +1 to move to 1.6 This should be made clear by making all plugin versions to bump to 3.0 (some of them are already there in relationship with Maven 3 minimum). And for all things which have problem we could make a branch from the latest releases and fix it there... Kind regards Karl Heinz Marbaise On 12/24/14 2:20 PM, Kristian Rosenvold wrote: Oops. Snappy contains 1.6 java bytecode, which breaks the build on maven plugins. We need to upgrade to 1.6; I'm taking this to the mailing list :) This 3.0.X has a 1.5 java requirement. The problem is that *everyone* is moving to 1.6 and it's getting increasingly hard to maintain a 1.5 code base. As an example, I have been moving code to apache commons, but we're basically unable to use this effort because commons is now 1.6. alternately I need to backport the code in a source-level-shading, but these things are getting silly. I propose the following: Make the 3.x line of plugins java 1.6+ only. Release all shared utilities in 1.6 versions in the 3.x version range. 3.0.X maven versions stay forever on the 2.x line of plugins and jdk 1.5. The most recent core version moves defaults to the 3.x range of plugins. The parent poms migrate to 3.x range some time in the near future. Keeping 3.0.x fixes to a minuimum (and critical stuff) only, will ensure that we can still stay 1.5 compatible here. Kristian 2014-12-24 13:52 GMT+01:00 Benson Margulies bimargul...@gmail.com: I don't have access to push a plexus-archiver release, could you please do the honors. Also, looks like my splitting job left some work behind in terms of the parent pom. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven AntRun Plugin version 1.8
Hi, my +1 ... anyone else? On 12/20/14 3:49 PM, Karl Heinz Marbaise wrote: Hi, We solved 8 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11125version=18043 There are still a couple of issues left in JIRA: http://jira.codehaus.org/issues/?jql=project%20%3D%20MANTRUN%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1107 https://repository.apache.org/content/repositories/maven-1107/org/apache/maven/plugins/maven-antrun-plugin/1.8/maven-antrun-plugin-1.8-source-release.zip Source release checksum(s): maven-antrun-plugin-1.8-source-release.zip sha1: bf8f70edf126ef814f9ddd8c28680f59c928c95e Staging site: http://maven.apache.org/plugins-archives/maven-antrun-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 - 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-1128] Fix mvn 2.2.1 build p...
GitHub user Tibor17 opened a pull request: https://github.com/apache/maven-surefire/pull/76 [SUREFIRE-1128] Fix mvn 2.2.1 build process https://builds.apache.org/view/All/job/maven-surefire-mvn-2.2.1 Fixed annoying issue related to JDK5/7 mvn verify -pl maven-failsafe-plugin -P run-its tested with java.home jdk5 [INFO] --- maven-invoker-plugin:1.9:run (integration-test) @ maven-failsafe-plugin --- [INFO] Building: jetty-war-test-failing\pom.xml [INFO] ..SKIPPED due to JRE version [INFO] Building: jetty-war-test-passing\pom.xml [INFO] ..SKIPPED due to JRE version [INFO] Building: multiple-summaries\pom.xml [INFO] ..SUCCESS (3.7 s) [INFO] Building: multiple-summaries-failing\pom.xml [INFO] ..SUCCESS (3.6 s) [INFO] Building: working-directory\pom.xml [INFO] ..SUCCESS (3.4 s) [INFO] - [INFO] Build Summary: [INFO] Passed: 3, Failed: 0, Errors: 0, Skipped: 2 [INFO] - tested with java.home jdk7 [INFO] --- maven-invoker-plugin:1.9:run (integration-test) @ maven-failsafe-plugin --- [INFO] Building: jetty-war-test-failing\pom.xml [INFO] run script verify.bsh.bsh [INFO] ..SUCCESS (7.5 s) [INFO] Building: jetty-war-test-passing\pom.xml [INFO] run script verify.bsh.bsh [INFO] ..SUCCESS (6.9 s) [INFO] Building: multiple-summaries\pom.xml [INFO] ..SUCCESS (3.6 s) [INFO] Building: multiple-summaries-failing\pom.xml [INFO] ..SUCCESS (3.7 s) [INFO] Building: working-directory\pom.xml [INFO] ..SUCCESS (3.4 s) [INFO] - [INFO] Build Summary: [INFO] Passed: 5, Failed: 0, Errors: 0, Skipped: 0 [INFO] - You can merge this pull request into a Git repository by running: $ git pull https://github.com/Tibor17/maven-surefire s2 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven-surefire/pull/76.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 #76 commit 00d88516aa5f401db12eff800ae93d189d398e79 Author: unknown digana.ti...@sk-za-04278.vsb Date: 2014-12-25T22:03:27Z [SUREFIRE-1128] Fix mvn 2.2.1 build process https://builds.apache.org/view/All/job/maven-surefire-mvn-2.2.1 --- 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 AntRun Plugin version 1.8
+1 Regards, Hervé Le samedi 20 décembre 2014 15:49:17 Karl Heinz Marbaise a écrit : Hi, We solved 8 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11125version=180 43 There are still a couple of issues left in JIRA: http://jira.codehaus.org/issues/?jql=project%20%3D%20MANTRUN%20AND%20status% 20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1107 https://repository.apache.org/content/repositories/maven-1107/org/apache/mav en/plugins/maven-antrun-plugin/1.8/maven-antrun-plugin-1.8-source-release.zi p Source release checksum(s): maven-antrun-plugin-1.8-source-release.zip sha1: bf8f70edf126ef814f9ddd8c28680f59c928c95e Staging site: http://maven.apache.org/plugins-archives/maven-antrun-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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
