Re: [VOTE] Release Apache Maven Mapping version 1.0
+1 On 11 August 2013 00:09, Dennis Lundberg denn...@apache.org wrote: Hi, This is a new shared component consisting of code from Maven WAR Plugin, that has been repackaged for reuse by other plugins. We solved 1 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName=Htmlversion=19526 There no issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11761component=16150status=1 Staging repo: https://repository.apache.org/content/repositories/maven-083/ https://repository.apache.org/content/repositories/maven-083/org/apache/maven/shared/maven-mapping/1.0/maven-mapping-1.0-source-release.zip Staging site: http://maven.apache.org/shared-archives/maven-mapping-1.0/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1512672 - /maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/apache/maven/plugin/gpg/AbstractGpgSigner.java
On 13 August 2013 18:53, Dennis Lundberg denn...@apache.org wrote: Hi Yeah, that was my @home new file template that kicked in. I've removed the @version tags now. @version is OK; just don't use $Date$. However just noticed that the code uses @author. The @author tag is deprecated in ASF code [1]. Briefly: - ASF is about community, not individuals - too difficult to maintain accurately Credit should be given elsewhere, e.g. in pom developer or contributor sections. [1] http://www.apache.org/foundation/records/minutes/2004/board_minutes_2004_09_22.txt section 7 F On Tue, Aug 13, 2013 at 12:48 PM, sebb seb...@gmail.com wrote: On 10 August 2013 13:27, denn...@apache.org wrote: Author: dennisl Date: Sat Aug 10 12:27:41 2013 New Revision: 1512672 URL: http://svn.apache.org/r1512672 Log: Add subversion keywords. Modified: maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/apache/maven/plugin/gpg/AbstractGpgSigner.java (contents, props changed) Modified: maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/apache/maven/plugin/gpg/AbstractGpgSigner.java URL: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/apache/maven/plugin/gpg/AbstractGpgSigner.java?rev=1512672r1=1512671r2=1512672view=diff == --- maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/apache/maven/plugin/gpg/AbstractGpgSigner.java (original) +++ maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/apache/maven/plugin/gpg/AbstractGpgSigner.java Sat Aug 10 12:27:41 2013 @@ -31,7 +31,7 @@ import org.apache.maven.project.MavenPro * A base class for all classes that implements signing of files. * * @author Dennis Lundberg - * @version $Revision: 1.1 $ $Date: 2004/07/28 09:48:35 2013-08-10 14:10 $ + * @version $Revision$ $Date$ Date causes problems. The value and format depends on the user's locale, so source archives will vary depending on where they were created. If you really need a timestamp (why?), use $Id$ instead. * @since 1.5 */ public abstract class AbstractGpgSigner Propchange: maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/apache/maven/plugin/gpg/AbstractGpgSigner.java -- svn:keywords = Date Revision Author Id - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Model Converter version 2.3
On 13 August 2013 18:58, Dennis Lundberg denn...@apache.org wrote: On Tue, Aug 13, 2013 at 12:30 AM, sebb seb...@gmail.com wrote: On 12 August 2013 20:10, Jason van Zyl ja...@tesla.io wrote: I have now read the threads that are referring to, and have not found a single link to any ASF rule stating that we need to include these things in a VOTE thread. So how do you propose that reviewers check the provenance of the files in the source release? Are you looking for files that are in a distribution that didn't come from source control? Everything else as far as provenance goes is covered. Errant content is a potential problem, but everything in a distribution should come from source control which no one has access to until they have a signed CLA on file. Yes. That is where the whole saga started. Proving provenance is why the SCM coordinates are needed for the vote. The SCM details may also be useful to discover files accidentally omitted from the source archive. You want to compare the contents of the *-source-release.zip with something from SCM, to make nothing bad has crept into the source bundle. So you need to know where in SCM you can find it. Have I understood you correctly? It's vital to be able to link the files in the source release archive(s) to their origin in SCM. The provenance of any source files the ASF releases must be clearly traceable. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Model Converter version 2.3
On 14 August 2013 09:47, sebb seb...@gmail.com wrote: On 13 August 2013 18:58, Dennis Lundberg denn...@apache.org wrote: On Tue, Aug 13, 2013 at 12:30 AM, sebb seb...@gmail.com wrote: On 12 August 2013 20:10, Jason van Zyl ja...@tesla.io wrote: I have now read the threads that are referring to, and have not found a single link to any ASF rule stating that we need to include these things in a VOTE thread. So how do you propose that reviewers check the provenance of the files in the source release? Are you looking for files that are in a distribution that didn't come from source control? Everything else as far as provenance goes is covered. Errant content is a potential problem, but everything in a distribution should come from source control which no one has access to until they have a signed CLA on file. Yes. That is where the whole saga started. Proving provenance is why the SCM coordinates are needed for the vote. The SCM details may also be useful to discover files accidentally omitted from the source archive. You want to compare the contents of the *-source-release.zip with something from SCM, to make nothing bad has crept into the source bundle. So you need to know where in SCM you can find it. Have I understood you correctly? It's vital to be able to link the files in the source release archive(s) to their origin in SCM. Simply not true. It is a nice convenience for somebody tracing the provenance of files in a source release, but it is by no means vital. The provenance of any source files the ASF releases must be clearly traceable. Being able to link the files in the source release archive(s) to their origin in SCM is certainly one way to make the provenance of source files the ASF releases easily traceable, but there is *no* foundation requirement for such. As I understand it, we *could*, as a project, decide to abandon SCM entirely for some specific module - something I would be strongly against - and we would be within our rights to do so. All that the foundation requires is that the PMC have verified the provenance of the files in the source releases they vote on. If you feel that individual members of the PMC are voting without having taken their required due diligence into account then I suggest you take that up with those individual members. -Stephen Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Model Converter version 2.3
On 14 August 2013 10:23, Stephen Connolly steph...@apache.org wrote: On 14 August 2013 09:47, sebb seb...@gmail.com wrote: On 13 August 2013 18:58, Dennis Lundberg denn...@apache.org wrote: On Tue, Aug 13, 2013 at 12:30 AM, sebb seb...@gmail.com wrote: On 12 August 2013 20:10, Jason van Zyl ja...@tesla.io wrote: I have now read the threads that are referring to, and have not found a single link to any ASF rule stating that we need to include these things in a VOTE thread. So how do you propose that reviewers check the provenance of the files in the source release? Are you looking for files that are in a distribution that didn't come from source control? Everything else as far as provenance goes is covered. Errant content is a potential problem, but everything in a distribution should come from source control which no one has access to until they have a signed CLA on file. Yes. That is where the whole saga started. Proving provenance is why the SCM coordinates are needed for the vote. The SCM details may also be useful to discover files accidentally omitted from the source archive. You want to compare the contents of the *-source-release.zip with something from SCM, to make nothing bad has crept into the source bundle. So you need to know where in SCM you can find it. Have I understood you correctly? It's vital to be able to link the files in the source release archive(s) to their origin in SCM. Simply not true. It is a nice convenience for somebody tracing the provenance of files in a source release, but it is by no means vital. What other means do you suggest then? The provenance of any source files the ASF releases must be clearly traceable. Being able to link the files in the source release archive(s) to their origin in SCM is certainly one way to make the provenance of source files the ASF releases easily traceable, but there is *no* foundation requirement for such. Is there any other way to check provenance? As I understand it, we *could*, as a project, decide to abandon SCM entirely for some specific module - something I would be strongly against - and we would be within our rights to do so. All that the foundation requires is that the PMC have verified the provenance of the files in the source releases they vote on. Which is not currently possible with the information provided in the vote e-mail. If you feel that individual members of the PMC are voting without having taken their required due diligence into account then I suggest you take that up with those individual members. I just want to make sure that the reviewers have the information they need to be able to do the due diligence. At present that is not possible from the information provided in the vote e-mails. -Stephen Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - - 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 - 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
[RESULT] [VOTE] Release Apache Maven Mapping version 1.0
Hi, The vote has passed with the following result: +1 (binding): Olivier Lamy, Dennis Lundberg, Stephen Connolly I will promote the artifacts to the central repo. On Sun, Aug 11, 2013 at 1:09 AM, Dennis Lundberg denn...@apache.org wrote: Hi, This is a new shared component consisting of code from Maven WAR Plugin, that has been repackaged for reuse by other plugins. We solved 1 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName=Htmlversion=19526 There no issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11761component=16150status=1 Staging repo: https://repository.apache.org/content/repositories/maven-083/ https://repository.apache.org/content/repositories/maven-083/org/apache/maven/shared/maven-mapping/1.0/maven-mapping-1.0-source-release.zip Staging site: http://maven.apache.org/shared-archives/maven-mapping-1.0/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Dennis Lundberg -- Dennis Lundberg
Re: [VOTE] Release Apache Maven Model Converter version 2.3
On 14 August 2013 10:45, sebb seb...@gmail.com wrote: On 14 August 2013 10:23, Stephen Connolly steph...@apache.org wrote: On 14 August 2013 09:47, sebb seb...@gmail.com wrote: On 13 August 2013 18:58, Dennis Lundberg denn...@apache.org wrote: On Tue, Aug 13, 2013 at 12:30 AM, sebb seb...@gmail.com wrote: On 12 August 2013 20:10, Jason van Zyl ja...@tesla.io wrote: I have now read the threads that are referring to, and have not found a single link to any ASF rule stating that we need to include these things in a VOTE thread. So how do you propose that reviewers check the provenance of the files in the source release? Are you looking for files that are in a distribution that didn't come from source control? Everything else as far as provenance goes is covered. Errant content is a potential problem, but everything in a distribution should come from source control which no one has access to until they have a signed CLA on file. Yes. That is where the whole saga started. Proving provenance is why the SCM coordinates are needed for the vote. The SCM details may also be useful to discover files accidentally omitted from the source archive. You want to compare the contents of the *-source-release.zip with something from SCM, to make nothing bad has crept into the source bundle. So you need to know where in SCM you can find it. Have I understood you correctly? It's vital to be able to link the files in the source release archive(s) to their origin in SCM. Simply not true. It is a nice convenience for somebody tracing the provenance of files in a source release, but it is by no means vital. What other means do you suggest then? That is not *your problem*. That is the *reviewers* problem. If the PMC reviewers decide that determining the provenance of files (which is a necessary part of their review) is too difficult because they are missing information that would assist them, then *they* will drive adding that information. The provenance of any source files the ASF releases must be clearly traceable. Being able to link the files in the source release archive(s) to their origin in SCM is certainly one way to make the provenance of source files the ASF releases easily traceable, but there is *no* foundation requirement for such. Is there any other way to check provenance? It is up to each individual PMC to put in place the procedure by which they check the provenance of the files they release, thus if a PMC decides to forgo SCM and return to the original HTTPD model of just releasing tarballs then the Foundation will require that they determine a method through which they can establish the provenance of the files they are releasing. As I understand it, we *could*, as a project, decide to abandon SCM entirely for some specific module - something I would be strongly against - and we would be within our rights to do so. All that the foundation requires is that the PMC have verified the provenance of the files in the source releases they vote on. Which is not currently possible with the information provided in the vote e-mail. The PMC members do not see a problem. If you feel that individual members of the PMC are voting without having taken their required due diligence into account then I suggest you take that up with those individual members. I just want to make sure that the reviewers have the information they need to be able to do the due diligence. At present that is not possible from the information provided in the vote e-mails. Again, the PMC are the reviewers that are required to perform their due diligence and do not see an issue with the email content. We see that we have all the information we require, we also do not want to add extra information than is required by us. -Stephen -Stephen Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - - 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 - 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:
Re: [VOTE] Release Apache Maven Model Converter version 2.3
On 14 August 2013 11:13, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 14 August 2013 10:45, sebb seb...@gmail.com wrote: On 14 August 2013 10:23, Stephen Connolly steph...@apache.org wrote: On 14 August 2013 09:47, sebb seb...@gmail.com wrote: On 13 August 2013 18:58, Dennis Lundberg denn...@apache.org wrote: On Tue, Aug 13, 2013 at 12:30 AM, sebb seb...@gmail.com wrote: On 12 August 2013 20:10, Jason van Zyl ja...@tesla.io wrote: I have now read the threads that are referring to, and have not found a single link to any ASF rule stating that we need to include these things in a VOTE thread. So how do you propose that reviewers check the provenance of the files in the source release? Are you looking for files that are in a distribution that didn't come from source control? Everything else as far as provenance goes is covered. Errant content is a potential problem, but everything in a distribution should come from source control which no one has access to until they have a signed CLA on file. Yes. That is where the whole saga started. Proving provenance is why the SCM coordinates are needed for the vote. The SCM details may also be useful to discover files accidentally omitted from the source archive. You want to compare the contents of the *-source-release.zip with something from SCM, to make nothing bad has crept into the source bundle. So you need to know where in SCM you can find it. Have I understood you correctly? It's vital to be able to link the files in the source release archive(s) to their origin in SCM. Simply not true. It is a nice convenience for somebody tracing the provenance of files in a source release, but it is by no means vital. What other means do you suggest then? That is not *your problem*. That is the *reviewers* problem. If the PMC reviewers decide that determining the provenance of files (which is a necessary part of their review) is too difficult because they are missing information that would assist them, then *they* will drive adding that information. As a member of the ASF, I do think it's my problem if software is being released in the name of the ASF. The ASF is about transparency - if it did not happen on a public mailing list then it did not happen. It should be possible for anyone to review a release and provide feedback to the PMC. At present the process is not transparent. The provenance of any source files the ASF releases must be clearly traceable. Being able to link the files in the source release archive(s) to their origin in SCM is certainly one way to make the provenance of source files the ASF releases easily traceable, but there is *no* foundation requirement for such. Is there any other way to check provenance? It is up to each individual PMC to put in place the procedure by which they check the provenance of the files they release, thus if a PMC decides to forgo SCM and return to the original HTTPD model of just releasing tarballs then the Foundation will require that they determine a method through which they can establish the provenance of the files they are releasing. As I understand it, we *could*, as a project, decide to abandon SCM entirely for some specific module - something I would be strongly against - and we would be within our rights to do so. All that the foundation requires is that the PMC have verified the provenance of the files in the source releases they vote on. Which is not currently possible with the information provided in the vote e-mail. The PMC members do not see a problem. If you feel that individual members of the PMC are voting without having taken their required due diligence into account then I suggest you take that up with those individual members. I just want to make sure that the reviewers have the information they need to be able to do the due diligence. At present that is not possible from the information provided in the vote e-mails. Again, the PMC are the reviewers that are required to perform their due diligence and do not see an issue with the email content. We see that we have all the information we require, we also do not want to add extra information than is required by us. -Stephen -Stephen Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - - 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
Re: [VOTE] Release Apache Maven Model Converter version 2.3
On 14 August 2013 12:01, sebb seb...@gmail.com wrote: As a member of the ASF, I do think it's my problem if software is being released in the name of the ASF. The ASF is about transparency - if it did not happen on a public mailing list then it did not happen. It should be possible for anyone to review a release and provide feedback to the PMC. At present the process is not transparent. As a member of the ASF, we elect a board to protect our responsibilities. The board delegates the responsibility of reviewing the provenance of source release bundles to each project's PMC. There is a chain of delegation of responsibilities from the members to the PMC. If any member feel that a specific PMC is not following their delegated responsibilities correctly, their first point of call is to send a mail detailing the issue to that PMC's private@ list. If that does not result in a satisfactory response, then they should address their concern to the board. If that does not result in a satisfactory response, then they can address the membership as a whole.
[VOTE] Release Maven Remote Resources Plugin 1.5
Hi, We solved 5 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11391version=18924 Staging repo: https://repository.apache.org/content/repositories/maven-093/ Subversion Revision: r1508060 Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 (NOTE: the cms wasn't responding this morning for publishing so if someone else wants to publish the site go for it. If it's required)
Re: [VOTE] Release Maven Remote Resources Plugin 1.5
On 14 August 2013 13:45, Jason van Zyl ja...@tesla.io wrote: Hi, We solved 5 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11391version=18924 Staging repo: https://repository.apache.org/content/repositories/maven-093/ Subversion Revision: r1508060 Thanks. However the SVN revision is not sufficient to identify the source, especially since the ASF uses multiple shared SVN repos. An appropriate base directory is also needed to identify which part of the tree was used. Since the tag is what is used in the POM scm entry, please specify the SVN tag name along with its revision. Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 (NOTE: the cms wasn't responding this morning for publishing so if someone else wants to publish the site go for it. If it's required) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Remote Resources Plugin 1.5
Here you go: https://svn.apache.org/repos/asf/maven/plugins/tags/maven-remote-resources-plugin-1.5/ I'll put it in the template for next time. On Aug 14, 2013, at 9:00 AM, sebb seb...@gmail.com wrote: On 14 August 2013 13:45, Jason van Zyl ja...@tesla.io wrote: Hi, We solved 5 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11391version=18924 Staging repo: https://repository.apache.org/content/repositories/maven-093/ Subversion Revision: r1508060 Thanks. However the SVN revision is not sufficient to identify the source, especially since the ASF uses multiple shared SVN repos. An appropriate base directory is also needed to identify which part of the tree was used. Since the tag is what is used in the POM scm entry, please specify the SVN tag name along with its revision. Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 (NOTE: the cms wasn't responding this morning for publishing so if someone else wants to publish the site go for it. If it's required) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -
Re: [VOTE] Release Maven Remote Resources Plugin 1.5
On 14 August 2013 14:08, Jason van Zyl ja...@tesla.io wrote: Here you go: https://svn.apache.org/repos/asf/maven/plugins/tags/maven-remote-resources-plugin-1.5/ Thanks again, however that was last updated: Last Changed Author: jvanzyl Last Changed Rev: 1513840 Last Changed Date: 2013-08-14 13:25:11 +0100 (Wed, 14 Aug 2013) which unfortunately does not agree with the originally stated revision: Subversion Revision: r1508060 I'll put it in the template for next time. Thanks, that would save a lot of hassle for everyone. On Aug 14, 2013, at 9:00 AM, sebb seb...@gmail.com wrote: On 14 August 2013 13:45, Jason van Zyl ja...@tesla.io wrote: Hi, We solved 5 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11391version=18924 Staging repo: https://repository.apache.org/content/repositories/maven-093/ Subversion Revision: r1508060 Thanks. However the SVN revision is not sufficient to identify the source, especially since the ASF uses multiple shared SVN repos. An appropriate base directory is also needed to identify which part of the tree was used. Since the tag is what is used in the POM scm entry, please specify the SVN tag name along with its revision. Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 (NOTE: the cms wasn't responding this morning for publishing so if someone else wants to publish the site go for it. If it's required) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Remote Resources Plugin 1.5
On 14 August 2013 14:14, sebb seb...@gmail.com wrote: On 14 August 2013 14:08, Jason van Zyl ja...@tesla.io wrote: Here you go: https://svn.apache.org/repos/asf/maven/plugins/tags/maven-remote-resources-plugin-1.5/ Thanks again, however that was last updated: Last Changed Author: jvanzyl Last Changed Rev: 1513840 Last Changed Date: 2013-08-14 13:25:11 +0100 (Wed, 14 Aug 2013) which unfortunately does not agree with the originally stated revision: However https://svn.apache.org/repos/asf/maven/plugins/tags/maven-remote-resources-plugin-1.5/ @1508060 is a perfectly valid immutable coordinate for the source code upon which this was created... Subversion Revision: r1508060 I'll put it in the template for next time. Thanks, that would save a lot of hassle for everyone. On Aug 14, 2013, at 9:00 AM, sebb seb...@gmail.com wrote: On 14 August 2013 13:45, Jason van Zyl ja...@tesla.io wrote: Hi, We solved 5 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11391version=18924 Staging repo: https://repository.apache.org/content/repositories/maven-093/ Subversion Revision: r1508060 Thanks. However the SVN revision is not sufficient to identify the source, especially since the ASF uses multiple shared SVN repos. An appropriate base directory is also needed to identify which part of the tree was used. Since the tag is what is used in the POM scm entry, please specify the SVN tag name along with its revision. Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 (NOTE: the cms wasn't responding this morning for publishing so if someone else wants to publish the site go for it. If it's required) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Remote Resources Plugin 1.5
On 14 August 2013 14:18, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 14 August 2013 14:14, sebb seb...@gmail.com wrote: On 14 August 2013 14:08, Jason van Zyl ja...@tesla.io wrote: Here you go: https://svn.apache.org/repos/asf/maven/plugins/tags/maven-remote-resources-plugin-1.5/ Thanks again, however that was last updated: Last Changed Author: jvanzyl Last Changed Rev: 1513840 Last Changed Date: 2013-08-14 13:25:11 +0100 (Wed, 14 Aug 2013) which unfortunately does not agree with the originally stated revision: However https://svn.apache.org/repos/asf/maven/plugins/tags/maven-remote-resources-plugin-1.5/ @1508060 is a perfectly valid immutable coordinate for the source code upon which this was created... That may be so, but it's not obvious without comparing the trees, as there were several changes to files between the revisions. Subversion Revision: r1508060 I'll put it in the template for next time. Thanks, that would save a lot of hassle for everyone. On Aug 14, 2013, at 9:00 AM, sebb seb...@gmail.com wrote: On 14 August 2013 13:45, Jason van Zyl ja...@tesla.io wrote: Hi, We solved 5 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11391version=18924 Staging repo: https://repository.apache.org/content/repositories/maven-093/ Subversion Revision: r1508060 Thanks. However the SVN revision is not sufficient to identify the source, especially since the ASF uses multiple shared SVN repos. An appropriate base directory is also needed to identify which part of the tree was used. Since the tag is what is used in the POM scm entry, please specify the SVN tag name along with its revision. Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 (NOTE: the cms wasn't responding this morning for publishing so if someone else wants to publish the site go for it. If it's required) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - - 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 Surefire Plugin version 2.16
Anyone? If I can't collect the results today, I won't be able to do it for another week or so. Am Sonntag, 11. August 2013 schrieb Andreas Gudian : Hi, We solved 13 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541version=19331 This release addresses some serious problems with character encodings in the test report XML files and adds a new Parallel Computer implementation to the JUnit 4.7+ provider, offering a bunch of new options and features around in-process parallel execution (submitted by Tibor17, thanks again!). There are still lots 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-085 https://repository.apache.org/content/repositories/maven-085/org/apache/maven/plugins/maven-surefire-plugin/2.16/maven-surefire-plugin-2.16-sources.jar https://repository.apache.org/content/repositories/maven-085/org/apache/maven/plugins/maven-failsafe-plugin/2.16/maven-failsafe-plugin-2.16-sources.jar Source: https://git-wip-us.apache.org/repos/asf/maven-surefire.git tag surefire-2.16_vote-1 Staging site: http://maven.apache.org/surefire-archives/maven-surefire-2.16/maven-surefire-plugin/index.html http://maven.apache.org/surefire-archives/maven-surefire-2.16/maven-failsafe-plugin/index.html http://maven.apache.org/surefire-archives/maven-surefire-2.16/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
Re: [VOTE] Release Maven Surefire Plugin version 2.16
Just saw your tag, BIG +1 for me, on no basis other than you seem to care about the quality of your work. On Wed, Aug 14, 2013 at 6:03 PM, Andreas Gudian andreas.gud...@gmail.comwrote: Anyone? If I can't collect the results today, I won't be able to do it for another week or so. Am Sonntag, 11. August 2013 schrieb Andreas Gudian : Hi, We solved 13 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541version=19331 This release addresses some serious problems with character encodings in the test report XML files and adds a new Parallel Computer implementation to the JUnit 4.7+ provider, offering a bunch of new options and features around in-process parallel execution (submitted by Tibor17, thanks again!). There are still lots 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-085 https://repository.apache.org/content/repositories/maven-085/org/apache/maven/plugins/maven-surefire-plugin/2.16/maven-surefire-plugin-2.16-sources.jar https://repository.apache.org/content/repositories/maven-085/org/apache/maven/plugins/maven-failsafe-plugin/2.16/maven-failsafe-plugin-2.16-sources.jar Source: https://git-wip-us.apache.org/repos/asf/maven-surefire.git tag surefire-2.16_vote-1 Staging site: http://maven.apache.org/surefire-archives/maven-surefire-2.16/maven-surefire-plugin/index.html http://maven.apache.org/surefire-archives/maven-surefire-2.16/maven-failsafe-plugin/index.html http://maven.apache.org/surefire-archives/maven-surefire-2.16/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
[ANN] Apache Maven Mapping 1.0 Released
The Maven team is pleased to announce the release of the Apache Maven Mapping, version 1.0 A shared component to assist in interpolating file names using properties from a Maven project. http://maven.apache.org/shared/maven-mapping/ You should specify the version in your project's dependency configuration: dependency groupIdorg.apache.maven.shared/groupId artifactIdmaven-mapping/artifactId version1.0/version /dependency Release Notes - Apache Maven Mapping - Version 1.0 Task * [MSHARED-291] Copy code for file name mapping from Maven WAR Plugin Enjoy, -The 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 Surefire Plugin version 2.16
+1 3 days pass so quickly Kristian 2013/8/14 Andreas Gudian andreas.gud...@gmail.com: Anyone? If I can't collect the results today, I won't be able to do it for another week or so. Am Sonntag, 11. August 2013 schrieb Andreas Gudian : Hi, We solved 13 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541version=19331 This release addresses some serious problems with character encodings in the test report XML files and adds a new Parallel Computer implementation to the JUnit 4.7+ provider, offering a bunch of new options and features around in-process parallel execution (submitted by Tibor17, thanks again!). There are still lots 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-085 https://repository.apache.org/content/repositories/maven-085/org/apache/maven/plugins/maven-surefire-plugin/2.16/maven-surefire-plugin-2.16-sources.jar https://repository.apache.org/content/repositories/maven-085/org/apache/maven/plugins/maven-failsafe-plugin/2.16/maven-failsafe-plugin-2.16-sources.jar Source: https://git-wip-us.apache.org/repos/asf/maven-surefire.git tag surefire-2.16_vote-1 Staging site: http://maven.apache.org/surefire-archives/maven-surefire-2.16/maven-surefire-plugin/index.html http://maven.apache.org/surefire-archives/maven-surefire-2.16/maven-failsafe-plugin/index.html http://maven.apache.org/surefire-archives/maven-surefire-2.16/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: [VOTE] Release Apache Maven Model Converter version 2.3
On Wed, Aug 14, 2013 at 10:47 AM, sebb seb...@gmail.com wrote: On 13 August 2013 18:58, Dennis Lundberg denn...@apache.org wrote: On Tue, Aug 13, 2013 at 12:30 AM, sebb seb...@gmail.com wrote: On 12 August 2013 20:10, Jason van Zyl ja...@tesla.io wrote: I have now read the threads that are referring to, and have not found a single link to any ASF rule stating that we need to include these things in a VOTE thread. So how do you propose that reviewers check the provenance of the files in the source release? Are you looking for files that are in a distribution that didn't come from source control? Everything else as far as provenance goes is covered. Errant content is a potential problem, but everything in a distribution should come from source control which no one has access to until they have a signed CLA on file. Yes. That is where the whole saga started. Proving provenance is why the SCM coordinates are needed for the vote. The SCM details may also be useful to discover files accidentally omitted from the source archive. You want to compare the contents of the *-source-release.zip with something from SCM, to make nothing bad has crept into the source bundle. So you need to know where in SCM you can find it. Have I understood you correctly? It's vital to be able to link the files in the source release archive(s) to their origin in SCM. The provenance of any source files the ASF releases must be clearly traceable. This information is clearly traceable and available to anyone who wants to review a release made by the Maven project. Our process uses the Release Plugin, which will put the POM from the SCM tag in the staging directory along with the source-release.zip. In that POM wou will find the URL to the original sources in SCM. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Model Converter version 2.3
On 14 August 2013 21:21, Dennis Lundberg denn...@apache.org wrote: On Wed, Aug 14, 2013 at 10:47 AM, sebb seb...@gmail.com wrote: On 13 August 2013 18:58, Dennis Lundberg denn...@apache.org wrote: On Tue, Aug 13, 2013 at 12:30 AM, sebb seb...@gmail.com wrote: On 12 August 2013 20:10, Jason van Zyl ja...@tesla.io wrote: I have now read the threads that are referring to, and have not found a single link to any ASF rule stating that we need to include these things in a VOTE thread. So how do you propose that reviewers check the provenance of the files in the source release? Are you looking for files that are in a distribution that didn't come from source control? Everything else as far as provenance goes is covered. Errant content is a potential problem, but everything in a distribution should come from source control which no one has access to until they have a signed CLA on file. Yes. That is where the whole saga started. Proving provenance is why the SCM coordinates are needed for the vote. The SCM details may also be useful to discover files accidentally omitted from the source archive. You want to compare the contents of the *-source-release.zip with something from SCM, to make nothing bad has crept into the source bundle. So you need to know where in SCM you can find it. Have I understood you correctly? It's vital to be able to link the files in the source release archive(s) to their origin in SCM. The provenance of any source files the ASF releases must be clearly traceable. This information is clearly traceable and available to anyone who wants to review a release made by the Maven project. Our process uses the Release Plugin, which will put the POM from the SCM tag in the staging directory along with the source-release.zip. In that POM wou will find the URL to the original sources in SCM. As has already been pointed out, SVN tags are not immutable, so the tag name alone is not sufficient. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg 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 Model Converter version 2.3
On 15 August 2013 08:53, sebb seb...@gmail.com wrote: On 14 August 2013 21:21, Dennis Lundberg denn...@apache.org wrote: On Wed, Aug 14, 2013 at 10:47 AM, sebb seb...@gmail.com wrote: On 13 August 2013 18:58, Dennis Lundberg denn...@apache.org wrote: On Tue, Aug 13, 2013 at 12:30 AM, sebb seb...@gmail.com wrote: On 12 August 2013 20:10, Jason van Zyl ja...@tesla.io wrote: I have now read the threads that are referring to, and have not found a single link to any ASF rule stating that we need to include these things in a VOTE thread. So how do you propose that reviewers check the provenance of the files in the source release? Are you looking for files that are in a distribution that didn't come from source control? Everything else as far as provenance goes is covered. Errant content is a potential problem, but everything in a distribution should come from source control which no one has access to until they have a signed CLA on file. Yes. That is where the whole saga started. Proving provenance is why the SCM coordinates are needed for the vote. The SCM details may also be useful to discover files accidentally omitted from the source archive. You want to compare the contents of the *-source-release.zip with something from SCM, to make nothing bad has crept into the source bundle. So you need to know where in SCM you can find it. Have I understood you correctly? It's vital to be able to link the files in the source release archive(s) to their origin in SCM. The provenance of any source files the ASF releases must be clearly traceable. This information is clearly traceable and available to anyone who wants to review a release made by the Maven project. Our process uses the Release Plugin, which will put the POM from the SCM tag in the staging directory along with the source-release.zip. In that POM wou will find the URL to the original sources in SCM. As has already been pointed out, SVN tags are not immutable, so the tag name alone is not sufficient. I think Stephen perfectly sum up the situation. If you're not happy follow that. But please STOP the troll! Thanks! Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Model Converter version 2.3
It's NOT trolling... If you feel trolled, grow some skin. On Thu, Aug 15, 2013 at 1:24 AM, Olivier Lamy ol...@apache.org wrote: On 15 August 2013 08:53, sebb seb...@gmail.com wrote: On 14 August 2013 21:21, Dennis Lundberg denn...@apache.org wrote: On Wed, Aug 14, 2013 at 10:47 AM, sebb seb...@gmail.com wrote: On 13 August 2013 18:58, Dennis Lundberg denn...@apache.org wrote: On Tue, Aug 13, 2013 at 12:30 AM, sebb seb...@gmail.com wrote: On 12 August 2013 20:10, Jason van Zyl ja...@tesla.io wrote: I have now read the threads that are referring to, and have not found a single link to any ASF rule stating that we need to include these things in a VOTE thread. So how do you propose that reviewers check the provenance of the files in the source release? Are you looking for files that are in a distribution that didn't come from source control? Everything else as far as provenance goes is covered. Errant content is a potential problem, but everything in a distribution should come from source control which no one has access to until they have a signed CLA on file. Yes. That is where the whole saga started. Proving provenance is why the SCM coordinates are needed for the vote. The SCM details may also be useful to discover files accidentally omitted from the source archive. You want to compare the contents of the *-source-release.zip with something from SCM, to make nothing bad has crept into the source bundle. So you need to know where in SCM you can find it. Have I understood you correctly? It's vital to be able to link the files in the source release archive(s) to their origin in SCM. The provenance of any source files the ASF releases must be clearly traceable. This information is clearly traceable and available to anyone who wants to review a release made by the Maven project. Our process uses the Release Plugin, which will put the POM from the SCM tag in the staging directory along with the source-release.zip. In that POM wou will find the URL to the original sources in SCM. As has already been pointed out, SVN tags are not immutable, so the tag name alone is not sufficient. I think Stephen perfectly sum up the situation. If you're not happy follow that. But please STOP the troll! Thanks! Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Surefire Plugin version 2.16
+1 On 12 August 2013 03:51, Andreas Gudian andreas.gud...@gmail.com wrote: Hi, We solved 13 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541version=19331 This release addresses some serious problems with character encodings in the test report XML files and adds a new Parallel Computer implementation to the JUnit 4.7+ provider, offering a bunch of new options and features around in-process parallel execution (submitted by Tibor17, thanks again!). There are still lots 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-085 https://repository.apache.org/content/repositories/maven-085/org/apache/maven/plugins/maven-surefire-plugin/2.16/maven-surefire-plugin-2.16-sources.jar https://repository.apache.org/content/repositories/maven-085/org/apache/maven/plugins/maven-failsafe-plugin/2.16/maven-failsafe-plugin-2.16-sources.jar Source: https://git-wip-us.apache.org/repos/asf/maven-surefire.git tag surefire-2.16_vote-1 Staging site: http://maven.apache.org/surefire-archives/maven-surefire-2.16/maven-surefire-plugin/index.html http://maven.apache.org/surefire-archives/maven-surefire-2.16/maven-failsafe-plugin/index.html http://maven.apache.org/surefire-archives/maven-surefire-2.16/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 -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
