all the credential info was correct; what I ended doing was invoke "deploy" locally to populate the archiva repo, and it worked for that failing upload - I re-enabled the deploy from Hudson, and it worked too the local "deploy" must have flushed or fixed something, but it was weird
On Tue, Jul 13, 2010 at 6:51 PM, Brett Porter <[email protected]> wrote: > all the security is at the repository level. There are two things to look at: > > - the info is sometimes erroneous when HTTP authentication is being used as > it tries first without the credentials, and then again with the credentials - > are there other problems around it? > - is it possible that the <distributionManagement> repository ID is > mismatched for that POM, so there is no matching u/p in settings.xml? > > Cheers, > Brett > > On 14/07/2010, at 8:17 AM, Shan Syed wrote: > >> I am getting this error: >> >> 2010-07-13 18:08:09,111 [btpool0-16] INFO >> org.apache.maven.archiva.security.ArchivaServletAuthenticator - >> Authorization Denied >> [ip=10.0.10.41,permission=archiva-upload-repository,repo=sk-snapshots] >> : no matching permissions >> >> for a single artifact in a multimodule build - the repository is set >> up fine, and my build machine has the correct settings(.xml) for >> accessing this repo AND all the other artifacts upload fine (WARs, >> JARs, ZIPs), it just dies on a particular one that really isn't >> different than other ones that are siblings to it the multimodule >> build >> >> in archiva I can see that the meta data is created correctly, it's >> just the upload that breaks >> >> is there any fine-grained per artifact security I need to look at? >> through archiva I have went in and deleted that artifact, same result >> next build >> >> Shan > > -- > Brett Porter > [email protected] > http://brettporter.wordpress.com/ > > > > >
