Re: [VOTE] Release Maven 3.1.1
On Sep 21, 2013, at 7:44 PM, sebb wrote: > On 22 September 2013 03:09, Jason van Zyl wrote: >> On Sep 21, 2013, at 6:16 PM, sebb wrote: >> >>> On 21 September 2013 23:09, Jason van Zyl wrote: >>> >>> It would still be automated. >>> However the source data would come form the vote e-mail, which makes >>> more sense to me. >>> >> >> If it were generated I would agree. Manually making an email is not >> automated or consistent. > > I don't care how the e-mail is created; it can be automated. > > What matters is that the content is understandable and complete. > Ok, then we agree. We should try to keep the vote email threads for the votes. I think what you asked for was the impetus for the tool I made and it helped do a more complete audit than I've ever done manually. But the SCM coordinates are not a requirement for the release email currently and if we're going to discuss that then we probably shouldn't hijack the vote threads which we both just did. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -
Re: [VOTE] Release Maven 3.1.1
On 22 September 2013 03:09, Jason van Zyl wrote: > On Sep 21, 2013, at 6:16 PM, sebb wrote: > >> On 21 September 2013 23:09, Jason van Zyl wrote: >> >> It would still be automated. >> However the source data would come form the vote e-mail, which makes >> more sense to me. >> > > If it were generated I would agree. Manually making an email is not automated > or consistent. I don't care how the e-mail is created; it can be automated. What matters is that the content is understandable and complete. >>> As part of the release the release revision should be made available for >>> use in the email. >> >> I agree the release revision needs to be part of the e-mail; that is >> what I have been requesting all along. >> That can then be used to ensure that the artifacts match the release vote, and that the sources match the SCM tag. The build.properties entry should be checked to ensure it is the same as the value from the release vote mail. >>> >>> I want to go in the direction of automation and to generate this as part of >>> the release so it will contain the revision. >> >> +1 >> >>> Going from a manually generated email is not a good solution. >> >> I disagree; so long as the e-mail has a reasonably standard format, it >> should be easy enough to extract the data to to the checks. > > Well, we'll just agree to disagree. Nothing made by a human is never going to > be as consistent as an automated process. I did not say that. However if a human uses an email template (as at present) the result should be sufficiently consistent that parsing would not be too difficult. > If I can get the sha1 for the release in an automated way, I'm not going to > cut and paste it from somewhere. I already grabbed the wrong one already in > one of the releases. There is no way you're going to convince me that once a > tool has been validated to yield the correct information that making a manual > email is better. Again, I don't care how the e-mail is created, so long as it contains all the required information in a readable format. >> >>> I can see the need for a secondary reference but I'm going to fully >>> automate it. >> >> It's not a secondary reference. >> The vote e-mail is the primary reference. >> >>> If I turn this tool into a Nexus Plugin I can potentially just generate the >>> email. >> >> Again, I think that's backwards. >> >> The point is that any reviewer needs to be able to check the release. >> >>> At any rate, I understand your concern to make sure there are no errant >>> files and I believe this tool addresses those concerns. >> >> The problem is that without the SCM coordinates it's not possible for >> a reviewer to independently check the source contents. >> They may use your tool to do so, or they may use other methods; that >> is up to them. >> The point is that it must be possible to independently audit the source >> release. >> > > You have the SCM coordinates now. I'm not sure what you mean by that. > Is the issue not addressed with the tool I made? Does the tool ensure that the SCM coordinates are included in the vote email? > There is no way that you will be able manually review the release as > accurately as the tool. When I review a release I don't only check files and sigs and hashes. I use a combination of tools and visual inspection. Sometimes the inspection turns up oddities that can then be added to the automated tooling. > You think it's useful to go file by file and manually check all the files? No, but it can pay to inspect some files. > That you are going to do it consistently and accurately without tooling? No, I never said that. > If you want to, all the information will be there in the releases I do from > now on from the report I'm generating and it's accurate and not susceptible > to my cut/paste errors. So long as the required information is in the vote e-mail, that's all I require. > If from the staging process the email is emitted along with the report then > you can do anything manually you wish but everything to that point will have > been created in a consistent, repeatable way that can be performed by someone > else (at least when I'm done). I'll just point out that there have been several plugin releases using the standard release process that added errant files to the source archive. Which is one reason why independent audits are needed. >> The vote e-mail chain is the official means by which releases are sanctioned. > > I have no issue sending an email. > >> Therefore the vote e-mail needs to contain all the required >> information; it should not be necessary for the reviewer to go digging >> for the information. >> > > Are you manually going to go through each of our releases file by file? No, but I may inspect some files. > If you are I will ask to put the revision in the template. Thanks, that's part of what I'm asking; the SCM URL is also needed. > After looking, and making the tool I don't think it's necessa
Re: [VOTE] Release Maven 3.1.1
On Sep 21, 2013, at 6:16 PM, sebb wrote: > On 21 September 2013 23:09, Jason van Zyl wrote: > > It would still be automated. > However the source data would come form the vote e-mail, which makes > more sense to me. > If it were generated I would agree. Manually making an email is not automated or consistent. >> As part of the release the release revision should be made available for use >> in the email. > > I agree the release revision needs to be part of the e-mail; that is > what I have been requesting all along. > >>> That can then be used to ensure that the artifacts match the release >>> vote, and that the sources match the SCM tag. >>> The build.properties entry should be checked to ensure it is the same >>> as the value from the release vote mail. >> >> I want to go in the direction of automation and to generate this as part of >> the release so it will contain the revision. > > +1 > >> Going from a manually generated email is not a good solution. > > I disagree; so long as the e-mail has a reasonably standard format, it > should be easy enough to extract the data to to the checks. Well, we'll just agree to disagree. Nothing made by a human is never going to be as consistent as an automated process. If I can get the sha1 for the release in an automated way, I'm not going to cut and paste it from somewhere. I already grabbed the wrong one already in one of the releases. There is no way you're going to convince me that once a tool has been validated to yield the correct information that making a manual email is better. > >> I can see the need for a secondary reference but I'm going to fully automate >> it. > > It's not a secondary reference. > The vote e-mail is the primary reference. > >> If I turn this tool into a Nexus Plugin I can potentially just generate the >> email. > > Again, I think that's backwards. > > The point is that any reviewer needs to be able to check the release. > >> At any rate, I understand your concern to make sure there are no errant >> files and I believe this tool addresses those concerns. > > The problem is that without the SCM coordinates it's not possible for > a reviewer to independently check the source contents. > They may use your tool to do so, or they may use other methods; that > is up to them. > The point is that it must be possible to independently audit the source > release. > You have the SCM coordinates now. Is the issue not addressed with the tool I made? There is no way that you will be able manually review the release as accurately as the tool. You think it's useful to go file by file and manually check all the files? That you are going to do it consistently and accurately without tooling? If you want to, all the information will be there in the releases I do from now on from the report I'm generating and it's accurate and not susceptible to my cut/paste errors. If from the staging process the email is emitted along with the report then you can do anything manually you wish but everything to that point will have been created in a consistent, repeatable way that can be performed by someone else (at least when I'm done). > The vote e-mail chain is the official means by which releases are sanctioned. I have no issue sending an email. > Therefore the vote e-mail needs to contain all the required > information; it should not be necessary for the reviewer to go digging > for the information. > Are you manually going to go through each of our releases file by file? If you are I will ask to put the revision in the template. After looking, and making the tool I don't think it's necessary. But if you are going to use no tooling and essentially do what I automated I will ask to add the source revision in the email. If this is for a theoretical reviewer who may want to do it, then I honestly don't think it's useful or necessary. >>> On Sep 20, 2013, at 5:40 PM, sebb wrote: > On 17 September 2013 16:39, Jason van Zyl wrote: >> Hi, >> >> Maven Core ITs are good, and the license/notice issue has been resolved >> so I'm rolling 3.1.1 again. >> >> Here is a link to Jira with 6 issues resolved: >> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18968 >> >> Staging repo: >> https://repository.apache.org/content/repositories/maven-065/ >> >> The distributable binaries and sources for testing can be found here: >> https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/ >> >> Specifically the zip, tarball, and source archives can be found here: >> https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.zip >> https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.tar.gz >> https://repository.apache.org/content/repositories/maven-065/o
Re: [VOTE] Release Maven 3.1.1
On 21 September 2013 23:09, Jason van Zyl wrote: > > On Sep 21, 2013, at 2:51 PM, sebb wrote: > >> On 21 September 2013 22:28, Jason van Zyl wrote: >>> You will now be infamous :-) >>> >>> https://github.com/jvanzyl/sebbalizer >>> >>> If you don't like the name, happy to change it. I thought it was >>> appropriate and meant as a compliment for being thorough. >> >> Thanks, but no thanks. >> Sorry, but I don't like the association. >> > > No problem. > > https://github.com/jvanzyl/source-release-validator Thanks. >>> With a given staging URL, groupId, artifact, and version it will retrieve >>> the source archive, and binary archive and the corresponding SHA1s and >>> validates the SHA1s are right. It unpacks both the archives, digs into the >>> binary archive to find the maven-core JAR to retrieve the build.properties >>> which contains the SHA1 of the release revision from which the source >>> archive was made. A git clone is performed and moved to the release >>> revision. A check is performed to ensure that each file in the source >>> archive is present in the release revision and that the SHA1 of the each >>> file in the source archive matches the SHA1 of the file from the >>> corresponding release revision. >>> >>> So for this release using the Sebbalizer I only found the DEPENDENCIES file >>> to not exist in the release revision, every other file I consider valid and >>> verified. I believe that for this release no errant files slipped in and >>> it's good. >>> >>> People should review the code. I spent an hour on this by yanking a bunch >>> of stuff together so it might very well have errors. I have one hardcoded >>> url for the Git repository but I'll pull that out of the POM and then >>> hopefully it can be used generally to validate source archives for releases. >> >> The general procedure seems fine, but the SCM coordinates still need >> to be in the release vote in order to tie everything together for the >> release vote, and for the historical record. >> >> Rather than pick out the details from the maven-core jar, the >> information should be taken from the release vote e-mail. > > No, I think an automated way is better. It would still be automated. However the source data would come form the vote e-mail, which makes more sense to me. > As part of the release the release revision should be made available for use > in the email. I agree the release revision needs to be part of the e-mail; that is what I have been requesting all along. >> That can then be used to ensure that the artifacts match the release >> vote, and that the sources match the SCM tag. >> The build.properties entry should be checked to ensure it is the same >> as the value from the release vote mail. > > I want to go in the direction of automation and to generate this as part of > the release so it will contain the revision. +1 > Going from a manually generated email is not a good solution. I disagree; so long as the e-mail has a reasonably standard format, it should be easy enough to extract the data to to the checks. > I can see the need for a secondary reference but I'm going to fully automate > it. It's not a secondary reference. The vote e-mail is the primary reference. > If I turn this tool into a Nexus Plugin I can potentially just generate the > email. Again, I think that's backwards. The point is that any reviewer needs to be able to check the release. > At any rate, I understand your concern to make sure there are no errant files > and I believe this tool addresses those concerns. The problem is that without the SCM coordinates it's not possible for a reviewer to independently check the source contents. They may use your tool to do so, or they may use other methods; that is up to them. The point is that it must be possible to independently audit the source release. The vote e-mail chain is the official means by which releases are sanctioned. Therefore the vote e-mail needs to contain all the required information; it should not be necessary for the reviewer to go digging for the information. > I think at this point with this it's not really necessary to put the release > revision in the email template but that's for the PMC to decide. I'll > continue to use the official template but I will also run this tool as part > of the core releases. >> >>> On Sep 20, 2013, at 5:40 PM, sebb wrote: >>> On 17 September 2013 16:39, Jason van Zyl wrote: > Hi, > > Maven Core ITs are good, and the license/notice issue has been resolved > so I'm rolling 3.1.1 again. > > Here is a link to Jira with 6 issues resolved: > https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18968 > > Staging repo: > https://repository.apache.org/content/repositories/maven-065/ > > The distributable binaries and sources for testing can be found here: > https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apac
Re: [VOTE] Release Maven 3.1.1
+1 --- Analyzing source release validity... stagingUrl: https://repository.apache.org/content/repositories/maven-065 groupId: org.apache.maven artifactId: apache-maven version: 3.1.1 Source ZIP url exists. https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.zip Source ZIP SHA1 url exists. https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.zip.sha1 Binary ZIP url exists. https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.zip Binary ZIP SHA1 url exists. https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.zip.sha1 Calculated SHA1 of source ZIP matches published SHA1 of source ZIP. 2251357aa47129674df578e787504b72cd57ed4d Calculated SHA1 of binary ZIP matches published SHA1 of binary ZIP. 8416a8f07f9bd36bbc775eaddda0693a35937fe9 LICENSE file is present in the source distribution. NOTICE file is present in the source distribution. LICENSE file is present in the binary distribution. NOTICE file is present in the binary distribution. Git revision of release as determined from maven-core-3.1.1.jar:org/apache/maven/messages/build.properties(buildNumber): 0728685237757ffbf44136acec0402957f723d9a All files in source distribution have been found in the release revision (taking into account acceptable exclusions). On Sep 17, 2013, at 8:39 AM, Jason van Zyl wrote: > Hi, > > Maven Core ITs are good, and the license/notice issue has been resolved so > I'm rolling 3.1.1 again. > > Here is a link to Jira with 6 issues resolved: > https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18968 > > Staging repo: > https://repository.apache.org/content/repositories/maven-065/ > > The distributable binaries and sources for testing can be found here: > https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/ > > Specifically the zip, tarball, and source archives can be found here: > https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.zip > https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.tar.gz > https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.zip > https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.tar.gz > > Source release checksum(s): > apache-maven-3.1.1-src.zip sha1: 2251357aa47129674df578e787504b72cd57ed4d > > Staging site: > http://people.apache.org/~jvanzyl/maven-3.1.1/ > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > Thanks, > > The Maven Team > Thanks, > > > > > > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -
CMS + svnpubsub explanations
I just published a documentation about CMS + svnpubsub for Maven, with schema for global overview of the differences and synchronization points between Maven site and components reference documentations [1] The documentation about Maven website is expected to be complete, but components reference documentation still needs improvements for people to better understand how the configuration is done. It can even be subject to discussion, since not every component uses the same process for the moment: one of my intents by doing this documentation is to be able to discuss with Maven devs to define our target convention. But for the moment, it is not possible since I know a lot of people are lost in different cases (and no, there is no CMS when we publish component reference documentation). Please review and tell if anything is not clear Regards, Hervé [1] http://maven.apache.org/developers/website/deploy-maven-website.html - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven 3.1.1
On Sep 21, 2013, at 2:51 PM, sebb wrote: > On 21 September 2013 22:28, Jason van Zyl wrote: >> You will now be infamous :-) >> >> https://github.com/jvanzyl/sebbalizer >> >> If you don't like the name, happy to change it. I thought it was appropriate >> and meant as a compliment for being thorough. > > Thanks, but no thanks. > Sorry, but I don't like the association. > No problem. https://github.com/jvanzyl/source-release-validator >> With a given staging URL, groupId, artifact, and version it will retrieve >> the source archive, and binary archive and the corresponding SHA1s and >> validates the SHA1s are right. It unpacks both the archives, digs into the >> binary archive to find the maven-core JAR to retrieve the build.properties >> which contains the SHA1 of the release revision from which the source >> archive was made. A git clone is performed and moved to the release >> revision. A check is performed to ensure that each file in the source >> archive is present in the release revision and that the SHA1 of the each >> file in the source archive matches the SHA1 of the file from the >> corresponding release revision. >> >> So for this release using the Sebbalizer I only found the DEPENDENCIES file >> to not exist in the release revision, every other file I consider valid and >> verified. I believe that for this release no errant files slipped in and >> it's good. >> >> People should review the code. I spent an hour on this by yanking a bunch of >> stuff together so it might very well have errors. I have one hardcoded url >> for the Git repository but I'll pull that out of the POM and then hopefully >> it can be used generally to validate source archives for releases. > > The general procedure seems fine, but the SCM coordinates still need > to be in the release vote in order to tie everything together for the > release vote, and for the historical record. > > Rather than pick out the details from the maven-core jar, the > information should be taken from the release vote e-mail. No, I think an automated way is better. As part of the release the release revision should be made available for use in the email. > That can then be used to ensure that the artifacts match the release > vote, and that the sources match the SCM tag. > The build.properties entry should be checked to ensure it is the same > as the value from the release vote mail. I want to go in the direction of automation and to generate this as part of the release so it will contain the revision. Going from a manually generated email is not a good solution. I can see the need for a secondary reference but I'm going to fully automate it. If I turn this tool into a Nexus Plugin I can potentially just generate the email. At any rate, I understand your concern to make sure there are no errant files and I believe this tool addresses those concerns. I think at this point with this it's not really necessary to put the release revision in the email template but that's for the PMC to decide. I'll continue to use the official template but I will also run this tool as part of the core releases. > >> On Sep 20, 2013, at 5:40 PM, sebb wrote: >> >>> On 17 September 2013 16:39, Jason van Zyl wrote: Hi, Maven Core ITs are good, and the license/notice issue has been resolved so I'm rolling 3.1.1 again. Here is a link to Jira with 6 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18968 Staging repo: https://repository.apache.org/content/repositories/maven-065/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/ Specifically the zip, tarball, and source archives can be found here: https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.zip https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.tar.gz https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.zip https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.tar.gz Source release checksum(s): apache-maven-3.1.1-src.zip sha1: 2251357aa47129674df578e787504b72cd57ed4d >>> >>> The full scm coordinates are needed. >>> The pom includes the git URL and tag, but that is not immutable. >>> Exactly the same tag was used for the previous vote. >>> >>> To identify the source archive uniquely, additional info such as a >>> hash is needed, so the hash is now included in the vote e-mail. >>> The same applies to the SCM tag. >>> Staging site: http://people.apache.org/~jvanzyl/maven-3.1.1/ Vote open for 72 hours. [ ]
Re: [VOTE] Release Maven 3.1.1
On 21 September 2013 22:28, Jason van Zyl wrote: > You will now be infamous :-) > > https://github.com/jvanzyl/sebbalizer > > If you don't like the name, happy to change it. I thought it was appropriate > and meant as a compliment for being thorough. Thanks, but no thanks. Sorry, but I don't like the association. > With a given staging URL, groupId, artifact, and version it will retrieve the > source archive, and binary archive and the corresponding SHA1s and validates > the SHA1s are right. It unpacks both the archives, digs into the binary > archive to find the maven-core JAR to retrieve the build.properties which > contains the SHA1 of the release revision from which the source archive was > made. A git clone is performed and moved to the release revision. A check is > performed to ensure that each file in the source archive is present in the > release revision and that the SHA1 of the each file in the source archive > matches the SHA1 of the file from the corresponding release revision. > > So for this release using the Sebbalizer I only found the DEPENDENCIES file > to not exist in the release revision, every other file I consider valid and > verified. I believe that for this release no errant files slipped in and it's > good. > > People should review the code. I spent an hour on this by yanking a bunch of > stuff together so it might very well have errors. I have one hardcoded url > for the Git repository but I'll pull that out of the POM and then hopefully > it can be used generally to validate source archives for releases. The general procedure seems fine, but the SCM coordinates still need to be in the release vote in order to tie everything together for the release vote, and for the historical record. Rather than pick out the details from the maven-core jar, the information should be taken from the release vote e-mail. That can then be used to ensure that the artifacts match the release vote, and that the sources match the SCM tag. The build.properties entry should be checked to ensure it is the same as the value from the release vote mail. > On Sep 20, 2013, at 5:40 PM, sebb wrote: > >> On 17 September 2013 16:39, Jason van Zyl wrote: >>> Hi, >>> >>> Maven Core ITs are good, and the license/notice issue has been resolved so >>> I'm rolling 3.1.1 again. >>> >>> Here is a link to Jira with 6 issues resolved: >>> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18968 >>> >>> Staging repo: >>> https://repository.apache.org/content/repositories/maven-065/ >>> >>> The distributable binaries and sources for testing can be found here: >>> https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/ >>> >>> Specifically the zip, tarball, and source archives can be found here: >>> https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.zip >>> https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.tar.gz >>> https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.zip >>> https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.tar.gz >>> >>> Source release checksum(s): >>> apache-maven-3.1.1-src.zip sha1: 2251357aa47129674df578e787504b72cd57ed4d >> >> The full scm coordinates are needed. >> The pom includes the git URL and tag, but that is not immutable. >> Exactly the same tag was used for the previous vote. >> >> To identify the source archive uniquely, additional info such as a >> hash is needed, so the hash is now included in the vote e-mail. >> The same applies to the SCM tag. >> >>> Staging site: >>> http://people.apache.org/~jvanzyl/maven-3.1.1/ >>> >>> Vote open for 72 hours. >>> >>> [ ] +1 >>> [ ] +0 >>> [ ] -1 >>> >>> Thanks, >>> >>> The Maven Team >>> Thanks, >>> >>> >>> >>> >>> >>> >> >> - >> 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 3.1.1
You will now be infamous :-) https://github.com/jvanzyl/sebbalizer If you don't like the name, happy to change it. I thought it was appropriate and meant as a compliment for being thorough. With a given staging URL, groupId, artifact, and version it will retrieve the source archive, and binary archive and the corresponding SHA1s and validates the SHA1s are right. It unpacks both the archives, digs into the binary archive to find the maven-core JAR to retrieve the build.properties which contains the SHA1 of the release revision from which the source archive was made. A git clone is performed and moved to the release revision. A check is performed to ensure that each file in the source archive is present in the release revision and that the SHA1 of the each file in the source archive matches the SHA1 of the file from the corresponding release revision. So for this release using the Sebbalizer I only found the DEPENDENCIES file to not exist in the release revision, every other file I consider valid and verified. I believe that for this release no errant files slipped in and it's good. People should review the code. I spent an hour on this by yanking a bunch of stuff together so it might very well have errors. I have one hardcoded url for the Git repository but I'll pull that out of the POM and then hopefully it can be used generally to validate source archives for releases. On Sep 20, 2013, at 5:40 PM, sebb wrote: > On 17 September 2013 16:39, Jason van Zyl wrote: >> Hi, >> >> Maven Core ITs are good, and the license/notice issue has been resolved so >> I'm rolling 3.1.1 again. >> >> Here is a link to Jira with 6 issues resolved: >> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18968 >> >> Staging repo: >> https://repository.apache.org/content/repositories/maven-065/ >> >> The distributable binaries and sources for testing can be found here: >> https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/ >> >> Specifically the zip, tarball, and source archives can be found here: >> https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.zip >> https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.tar.gz >> https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.zip >> https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.tar.gz >> >> Source release checksum(s): >> apache-maven-3.1.1-src.zip sha1: 2251357aa47129674df578e787504b72cd57ed4d > > The full scm coordinates are needed. > The pom includes the git URL and tag, but that is not immutable. > Exactly the same tag was used for the previous vote. > > To identify the source archive uniquely, additional info such as a > hash is needed, so the hash is now included in the vote e-mail. > The same applies to the SCM tag. > >> Staging site: >> http://people.apache.org/~jvanzyl/maven-3.1.1/ >> >> Vote open for 72 hours. >> >> [ ] +1 >> [ ] +0 >> [ ] -1 >> >> Thanks, >> >> The Maven Team >> Thanks, >> >> >> >> >> >> > > - > 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 -
maven-wagon pull request: Wagon HTTP upgraded to HttpClient 4.3
GitHub user ok2c reopened a pull request: https://github.com/apache/maven-wagon/pull/3 Wagon HTTP upgraded to HttpClient 4.3 Upgrades Apache HttpClient used by HTTP wagon to version 4.3 http://jira.codehaus.org/browse/WAGON-402 You can merge this pull request into a Git repository by running: $ git pull https://github.com/ok2c/maven-wagon httpclient-4.3 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven-wagon/pull/3.patch - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
maven-wagon pull request: Wagon HTTP upgraded to HttpClient 4.3
Github user ok2c closed the pull request at: https://github.com/apache/maven-wagon/pull/3 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
