I'll write up the procedure on the Gradle wiki for deploying to nexus which solves these issues with deploying via codehaus.
On 13/12/2010, at 9:31 PM, Graeme Rocher <[email protected]> wrote: > We also had this problem with some of the NoSQL jars we published and > it is a serious problem. > > A previous workaround I used was to to publish first with the > webdav-jackrabbit wagon (1.0-beta-7) > > Unfortunately this resulted in bad SHA1 signatures so afterwards I > published again using the plain HTTP wagon > "org.apache.maven.wagon:wagon-http:1.0-beta-6" > > Note you can't publish the first time with the plain HTTP wagon > because it fails to create the proper directory structure > > This worked once, but recently I tried the same process and failed > miserably. I had to generate valid SHA1 files for each jar/pom and > manually connect to the Codehaus repo and overwrite them by hand to > fix the problem :-( > > Cheers > > On Mon, Dec 13, 2010 at 10:59 AM, Vaclav Pech <[email protected]> wrote: >> Thank you, Adam, for the suggestions. >> >>> >>> - try a new version of the webdav-jackrabbit wagon (1.0-beta-7) >>> - don't swallow exceptions when configuring the uploadArchives task. The >>> GPars build has a big fat try/catch block around it which throws the >>> exception away. It's possible something is going wrong when configuring the >>> task, but this is not being reported because the exception is discarded. >> >> I've upgraded jackrabbit as well as removed the exception handling, >> unfortunately without any effect. >> >>> >>> >>> Regards, >>> >>> Vaclav >>> >>> >>> >>> On Sat, Dec 11, 2010 at 7:48 PM, Russel Winder <[email protected]> >>> wrote: >>>> >>>> Hi, >>>> >>>> The GPars Gradle build is causing faulty SHA1 signatures to be written >>>> in the Codehaus repository during an uploadArchives task. This is >>>> something specific to the GPars build, since if I do a Gant >>>> uploadArchives on the same machine to the same Codehaus snapshots >>>> repository the SHA1 signatures written are correct. Certainly I think >>>> we can rule out my machine as the culprit and also Codehaus -- at least >>>> per se. >>>> >>>> I am at a loss as to understand what the Gradle-related factors are >>>> here. Has anyone seen this sort of thing before? Any ideas as to what >>>> experiments we might try to see if we can narrow down what the problem >>>> is in the GPars Gradle build? >>>> >>>> Thanks. >>>> >>>> -- >>>> Russel. >>>> >>>> ============================================================================= >>>> Dr Russel Winder t: +44 20 7585 2200 voip: >>>> sip:[email protected] >>>> 41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected] >>>> London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder >>> >>> >>> >>> -- >>> E-mail: [email protected] >>> Blog: http://www.jroller.com/vaclav >>> Linkedin page: http://www.linkedin.com/in/vaclavpech >>> >>> >>> -- >>> Adam Murdoch >>> Gradle Developer >>> http://www.gradle.org >>> CTO, Gradle Inc. - Gradle Training, Support, Consulting >>> http://www.gradle.biz >>> >> >> >> >> -- >> E-mail: [email protected] >> Blog: http://www.jroller.com/vaclav >> Linkedin page: http://www.linkedin.com/in/vaclavpech >> > > > > -- > Graeme Rocher > Grails Project Lead > SpringSource - A Division of VMware > http://www.springsource.com > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
