Re: 405 Method not allowed
Hi, have you set up either username/password on the maven side or anonymous access in Archiva? Kristof javijava wrote: Hi to all! .I'm not sure where can i post my question: I have a Maven local repo managed by Apache archiva.Well now, i'm trying to do a mvn release,and after modify the local pom of the project i have a build error: svn: Commitfailed (details follow) svn: PROPFIND request failed on '/(project)' svn: PROPFIND of '/(project)' : 405 Method not allowed. In server we have: .a SVN repo with the user configured in passwd file. .Access http via Apache2 (here i don't demand users, just put de path of repo) .Apache Archiva Someone knows where must be the problem? thanks a lot!
Re: Repository scanning problem in 1.0?
I don't know if this is related, but now I see a NPE in the logs when using Update Database Now: jvm 1| 2007-11-29 14:16:03,340 [Thread-6] ERROR org.codehaus.plexus.taskqueue.execution.TaskQueueExecutor:database-u pdate - Error executing task jvm 1| edu.emory.mathcs.backport.java.util.concurrent.ExecutionException: java.lang.NullPointerException jvm 1| at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.getResult(FutureTask.java:299) jvm 1| at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.get(FutureTask.java:118) jvm 1| at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.waitForTask(Thread edTaskQueueExecutor.java:159) jvm 1| at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQu eueExecutor.java:127) jvm 1| Caused by: jvm 1| java.lang.NullPointerException jvm 1| at org.apache.maven.archiva.database.updater.ProcessArchivaArtifactClosure.execute(ProcessArchivaArtifac tClosure.java:56) jvm 1| at org.apache.commons.collections.CollectionUtils.forAllDo(CollectionUtils.java:388) jvm 1| at org.apache.maven.archiva.database.updater.JdoDatabaseUpdater.updateProcessed(JdoDatabaseUpdater.java: 170) jvm 1| at org.apache.maven.archiva.database.updater.JdoDatabaseUpdater.updateAllProcessed(JdoDatabaseUpdater.ja va:111) jvm 1| at org.apache.maven.archiva.scheduled.executors.ArchivaDatabaseUpdateTaskExecutor.executeTask(ArchivaDat abaseUpdateTaskExecutor.java:78) jvm 1| at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTask QueueExecutor.java:116) jvm 1| at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) jvm 1| at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176) jvm 1| at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.j ava:665) jvm 1| at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java: 690) jvm 1| at java.lang.Thread.run(Thread.java:801) ArneD wrote: Hi all, first of all, congratulations to all Archiva developers for releasing the 1.0 version! I started playing around with it a little bit, and ran into the following problem: After starting up a fresh instance with default configuration, I copied parts of my existing repository to Archiva's default internal repository. Then I used the Scan Repository Now button on the repository administration page. Afterwards, all artifacts were visible on the Browse page. So far so good. I then copied some more groups of my existing repo to Archiva's default internal repository, and used Scan Repository Now once again. But this time, the Browse page did not show the newly added groups. This was quite surprising, as the log output of RepositoryScanner clearly showed that Archiva DID walk over these new artifacts, without errors or warnings. I tried to use the Update Database Now button, but still no effect. I finally touched one of the POM files in the missing groups, i.e. I gave the POM file a new timestamp. After doing Scan Repository Now again, the artifact appeared on the Browse page. When browsing into the artifact, however, I get the error message Unable to find project model for [...]. Seems like a bug to me? I know that my playground scenario may be a little bit unusual, but I would expect that Archiva should always be able to synchronize itself to the file system contents, regardless of the files' timestamps. Thanks - Arne -- View this message in context: http://www.nabble.com/Repository-scanning-problem-in-1.0--tf4897121.html#a14025508 Sent from the archiva-users mailing list archive at Nabble.com.
Re: Repository scanning problem in 1.0?
Wendy Smoak-3 wrote: On Nov 29, 2007 6:07 AM, ArneD [EMAIL PROTECTED] wrote: After starting up a fresh instance with default configuration, I copied parts of my existing repository to Archiva's default internal repository. Then I used the Scan Repository Now button on the repository administration page. Afterwards, all artifacts were visible on the Browse page. So far so good. I then copied some more groups of my existing repo to Archiva's default internal repository, and used Scan Repository Now once again. But this time, the Browse page did not show the newly added groups. This was quite surprising, as the log output of RepositoryScanner clearly showed that Archiva DID walk over these new artifacts, without errors or warnings. I tried to use the Update Database Now button, but still no effect. I finally touched one of the POM files in the missing groups, i.e. I gave the POM file a new timestamp. After doing Scan Repository Now again, the artifact appeared on the Browse page. When browsing into the artifact, however, I get the error message Unable to find project model for [...]. I've seen Unable to find project model for [...] in recent versions of Archiva, also using with existing repository contents, but have not been able to isolate it with publicly available repo data. Can you come up with steps to reproduce this, and attach zipped repository contents to a JIRA issue? It shouldn't take more than a few artifacts to provoke the problem, once you know the cause. http://jira.codehaus.org/browse/MRM Thanks, -- Wendy I filed http://jira.codehaus.org/browse/MRM-608 for the unable to find project model problem. Do you think the repository scanning problem as such, as described in my original mail, should be filed as a second issue? Thanks - Arne -- View this message in context: http://www.nabble.com/Repository-scanning-problem-in-1.0--tf4897121.html#a14026445 Sent from the archiva-users mailing list archive at Nabble.com.