Any way to ignore LayoutExceptions?
I've deployed an artifact that does not have the same name as its parent module (long story) and I can't retrieve it, getting this exception: org.apache.maven.archiva.repository.layout.LayoutException: Invalid path to Artifact: filename format is invalid, should start with artifactId as stated in path. Is there any way I can prevent Archiva from enforcing this restriction? Thanks, Carlton - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you.
Archiva selectively failing to proxy one particular artifact
I have a strange problem where an Archiva instance absolutely refuses to retrieve one particular artifact from central under any circumstances... it is /org/apache/maven/maven/2.0.6/maven-2.0.6.pom . I've verified that the instance can retrieve other artifacts, in fact maven-2.0.5.pom retrieves just fine, as well as other randomly selected jars and pom files. It's only maven-2.0.6.pom that it fails on. I also verified that the file is in fact on maven central. When I say I'm testing it, I mean that I'm pointing a browser to the archiva URL designating an artifact that is not yet proxied, for example http://myarchivahost/archiva/repository/myrepo/org/apache/maven/2.0.6/ma ven-2.0.6.pom which returns a 404 error message. Also, I don't know if this is related or not, but the 404 message displays a munged, invalid URL: The following resource does not exist: http://myarchivahost/repository/org/apache/maven/2.0.6/maven-2.0.6.pom http://myarchivahost/repository/org/apache/maven/2.0.6/maven-2.0.6.pom Notice that the the context string archiva doesn't appear in the displayed URL, and neither does the repository name myrepo. But since this behavior is reproducible with other well-formed URL's for nonexistent artifacts, this may not be related to my problem at all. Thanks in advance... - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you.
RE: Archiva selectively failing to proxy one particular artifact
It populates just an empty 2.0.6 directory. The behavior is the same whether that dir is pre-existing or not. I guess I could try installing that artifact by hand and see what happens. I've also tried restarting tomcat as well. I'm not sure how I might go about restoring the state other than that. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Thursday, February 28, 2008 4:45 PM To: archiva-users@maven.apache.org Subject: Re: Archiva selectively failing to proxy one particular artifact it works for me, so there must be a state problem rather than a bug in the proxying related to that artifact. Do you have any content for that version in the managed repository? - Brett On 29/02/2008, Brown, Carlton [EMAIL PROTECTED] wrote: I have a strange problem where an Archiva instance absolutely refuses to retrieve one particular artifact from central under any circumstances... it is /org/apache/maven/maven/2.0.6/maven-2.0.6.pom . I've verified that the instance can retrieve other artifacts, in fact maven-2.0.5.pom retrieves just fine, as well as other randomly selected jars and pom files. It's only maven-2.0.6.pom that it fails on. I also verified that the file is in fact on maven central. When I say I'm testing it, I mean that I'm pointing a browser to the archiva URL designating an artifact that is not yet proxied, for example http://myarchivahost/archiva/repository/myrepo/org/apache/maven/2.0.6/ ma ven-2.0.6.pom which returns a 404 error message. Also, I don't know if this is related or not, but the 404 message displays a munged, invalid URL: The following resource does not exist: http://myarchivahost/repository/org/apache/maven/2.0.6/maven-2.0.6.pom http://myarchivahost/repository/org/apache/maven/2.0.6/maven-2.0.6.po m Notice that the the context string archiva doesn't appear in the displayed URL, and neither does the repository name myrepo. But since this behavior is reproducible with other well-formed URL's for nonexistent artifacts, this may not be related to my problem at all. Thanks in advance... - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you. -- Brett Porter Blog: http://blogs.exist.com/bporter/
Derby database relative to `cwd` ?
In my latest Archiva installation, I noticed that Archiva resolves the path to the derby database relative to whatever was the current working directory at the time Tomcat was started. For example, if I'm in $CATALINA_HOME/bin and I run ./catalina.sh start, then the derby database gets created under $CATALINA_HOME/bin/archiva/derbydb.If I restart Tomcat later from a different directory, it gets created from scratch in that different directory. To work around this issue and make sure the derby db dir is always resolved to the same place, before Tomcat starts in catalina.sh, I must explicitly call: cd $CATALINA_HOME Here's part of my archiva.xml, where the path to the derby db gets set: Resource name=jdbc/users auth=Container type=javax.sql.DataSource username=sa password= driverClassName=org.apache.derby.jdbc.EmbeddedDriver url=jdbc:derby:archiva/derbydb;create=true / And in catalina.properties I have this: appserver.home=${catalina.home} appserver.base=${catalina.home}/archiva This is Archiva 1.0.1 on Tomcat 6.0.16 with JDK 1.6.0_04, RHEL 5 Thanks in advance, Carlton - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you.
RE: Archiva crashes after a couple of days
-Original Message- From: Eric Miles [mailto:[EMAIL PROTECTED] Sent: Friday, February 22, 2008 4:07 PM To: archiva-users@maven.apache.org Subject: RE: Archiva crashes after a couple of days I too had this same issue. Make sure your cron syntax is correct as it is not standard unix cron syntax. The first entry is a second number, not minutes. I initially (and accidentally) setup our cron jobs to run at a crazy pace, I think every second. Me three. I didn't see any reason not to scan every minute, but in fact it was every second. Result - massive log files, Archiva hung. Did not have to reinstall it, though. The cron setup would be a good candidate for improved input forms and/or validation. - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you.
Reverse artifact lookup?
Hi all, This question may in fact be generalized to Maven, but I'm wondering if there is any reverse lookup mechanism for jar artifacts. For example, I have this mystery dependency called foo.jar. Is there a way to query a Maven-compliant repository to search on the checksum to determine the group, module, revision, etc? I think Archiva has this feature, but could it proxy such a query to the Maven 2 repository? Thanks, Carlton - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you.
Artifacts not being indexed
Hi, I've got a problem where an artifact downloaded to the filesystem cannot be browsed. There's some problem with either the database scanning or repository indexing. The maven metadata files are not being generated. The pom file appears to be good. How can I troubleshoot this problem and determine whether it's the database failing to pick it up, or archiva failing to index it, or something else? Would there be errors written to a log somewhere? I've checked archiva.log which shows nothing except the requests for the scanning and indexing tasks. This is a frequent problem I've been having, it would be good if there were some good diagnostics for indexing problems. -Carlton - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you.
RE: Artifacts not being indexed
-Original Message- From: Wendy Smoak [mailto:[EMAIL PROTECTED] Sent: Friday, February 15, 2008 1:17 PM To: archiva-users@maven.apache.org Subject: Re: Artifacts not being indexed On Fri, Feb 15, 2008 at 11:06 AM, Brown, Carlton [EMAIL PROTECTED] wrote: I've got a problem where an artifact downloaded to the filesystem cannot be browsed. There's some problem with either the database scanning or repository indexing. The maven metadata files are not being generated. The pom file appears to be good. By downloaded, do you mean you are using Archiva as a proxy? Or do you have an external process that is writing to the filesystem? External process writing to the filesystem. The first thing I'd track down is why there is no metadata file. There is a checkbox in the Archiva config that will make it create missing metadata files. Try checking that box and then clicking 'scan' and then 'update database'. Does it now show up in browse? It does not. That checkbox appears to be enabled by default, and I have been doing 'scan' and 'update database', so no luck there. Strangely, when this happens, the artifacts show up in a search, but you can't browse to them. I mean they don't show up under the /archiva/browse URL, you can use the /repository URL and see them there just fine. (I've seen it create missing metadata files. I'm less sure about its ability to repair broken ones.) It does create missing metadata files, but the process seems to be very hit-or-miss, and shows almost nothing in the way of useful feedback or diagnostics. Is there some other, more decisive manual way to force it to re-scan the entire filesystem and recreate the metadata files? - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you.
Browsing error - Unable to find project model
I'm getting this error unable to find project model when I browse down to a particular module, even though the POM and metadata are there, and I've force the database to rescan. What's going on and and how do I need to fix it? TIA, Carlton - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you.
How to force a retrieval without using maven
Hi all, Is there a simple way to test whether Archiva can retrieve a certain artifact from the central maven repository without going through all the Maven client-side configuration? I was thinking just to point my browser at the Archiva repository with the URL of a non-existent artifact to see if this will force it to be retrieved from central, but this just gave me a 404 error. I am using the default internal repository and remote proxies as configured out of the box. TIA, Carlton - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you.