Thanks Justin. On closer inspection there was another difference with the Java broker package that I hadnt spotted, so the full rebuild was a good call.
Looking it over again I notice that the SVN revision doesnt seem to have been passed through the release correctly somehow, the Java components embed it into properties files for version reporting but it is simply showing up as a dash in the files, although I tried running the release myself (using ./release.sh branches/0.14/qpid 1209041 0.14) and it seemed to work fine? I dont necessarily think it warrants another respin, but it'd be good to work out what happened and avoid it for future releases. I also tried to upload the maven artifacts to a staging repo on the Nexus instance but couldnt as as the signature files are required artifacts. Robbie On 15 December 2011 19:09, Justin Ross <[email protected]> wrote: > I went ahead and produced the fixed distribution. The original is still > there under a very long name. > > before: > http://people.apache.org/~jross/qpid-0.14-before-restoring-missing-maven-artifacts/maven/org/apache/qpid/ > after: http://people.apache.org/~jross/qpid-0.14/maven/org/apache/qpid/ > > Justin > > > On Thu, 15 Dec 2011, Justin Ross wrote: > >> On Thu, 15 Dec 2011, Robbie Gemmell wrote: >> >>> The maven artifacts folder doesnt seem to contain everything I >>> expected it should. Only the client and common artifacts are present, >>> whereas Andrew had previously added additional artifacts which are >>> mentioned in the ivy.xml file used for upload and the release.sh >>> script. Was an old copy of the release script possibly used to >>> generate the build? >> >> >> That's precisely what I did wrong. Thanks for catching this. I'll >> rebuild the RC2 distribution now from the same revision, but properly with >> the current release script. >> >>> Everything else I tested (Java broker, client, management artifacts) >>> seemed fine and I was on course to just vote positively until I >>> noticed that. >>> >>> Do you happen to still have the build folder used to generate the >>> artifacts to see if they were actually built? Either they still exist >>> and we use them, or we decide to rebuild them, or we just modify the >>> ivy.xml file and upload the existing artifacts without them. Thoughts? >> >> >> I think the rebuild will be the most straightforward, so long as that's >> acceptable. (Fwiw, I've checked my build folder, and the remaining >> artifacts are present afaict.) >> >>> Robbie >>> >>> On 12 December 2011 14:58, Justin Ross <[email protected]> wrote: >>>> >>>> Hello, everyone. There have been no new changes on the release branch >>>> since >>>> our proposed final RC, available here: >>>> >>>> http://people.apache.org/~jross/qpid-0.14/ >>>> >>>> If you favor releasing this distribution as Qpid 0.14, vote +1. If >>>> instead >>>> you think there are problems that should prevent this distribution from >>>> being released, vote -1. >>>> >>>> I'd like to complete the vote by Thursday so I can push the release >>>> Friday, >>>> provided we vote in favor. >>>> >>>> Thanks, everyone, for all your help getting the release out. >>>> >>>> Justin >>>> >>>> --- >>>> 0.14 release page: https://cwiki.apache.org/qpid/014-release.html >>>> >>>> >>>> --------------------------------------------------------------------- >>>> Apache Qpid - AMQP Messaging Implementation >>>> Project: http://qpid.apache.org >>>> Use/Interact: mailto:[email protected] >>>> >>> >>> --------------------------------------------------------------------- >>> Apache Qpid - AMQP Messaging Implementation >>> Project: http://qpid.apache.org >>> Use/Interact: mailto:[email protected] >>> >>> >> > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
