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


Reply via email to