Archiva

Archiva does not download plugin artifacts in Geronimo

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.0.1
  • Fix Version/s: 1.0.2
  • Component/s: None
  • Labels:
    None
  • Environment:
    Ubuntu 7.10 x64, jdk1.6.0_04 x64, geronimo 2.0.2, maven 2.0.8 on client
  • Number of attachments :
    5

Description

When i have an initially blank local maven repo and for example start maven with "mvn clean", no artifacts get downloaded. Maven is configured via the attached settings.xml. When i monitor the tcp traffic, i see that the GET (in this case for the maven-metadata.xml for maven-clean-plugin) request issued to archiva is the correct one. Archiva responses with a 404.

When I browse the repository file system on the server where archiva stores its files, i see that a maven-metadata-central.xml was stored. the contents of this file are not correct, though.

From trial and error I found out, that any request to a plugin related maven-metadata.xml file will fail. If I try the same for a "normal" artifact maven-metadata.xml (like the one for commons-lang) then archiva downloads the correct file.

  1. maven-resources-plugin-maven-metadata-central.xml
    09/Mar/08 10:02 PM
    0.4 kB
    Maria Odea Ching
  2. MRM727.diff
    04/Mar/08 5:12 AM
    1 kB
    Christian Domsch
  3. MRM-727-build-stack-trace.txt
    09/Mar/08 9:59 PM
    14 kB
    Maria Odea Ching
  4. MRM-727-geronimo-tomcat-log-0.0.0.0_access_log.2008-03-10.txt
    09/Mar/08 10:06 PM
    13 kB
    Maria Odea Ching
  5. settings-wrong.xml
    03/Mar/08 9:19 PM
    0.5 kB
    Christian Domsch

Issue Links

Activity

Hide
Christian Domsch added a comment -

I debugged through archiva and found out, that one reason for this bug, is that in DefaultRepositoryProxyConnectors in line 405 the filename for the local repo file gets renamed from maven-metadata.xml to maven-metadata-central.xml. This causes a problem later on, when this file is accessed because 1. the file never gets found by maven and 2. if you try to access it directly ProxiedDavServer fails to recognize it as a metadata file because the check in line 341 compares it to the string "maven-metadata.xml" and fails.

Show
Christian Domsch added a comment - I debugged through archiva and found out, that one reason for this bug, is that in DefaultRepositoryProxyConnectors in line 405 the filename for the local repo file gets renamed from maven-metadata.xml to maven-metadata-central.xml. This causes a problem later on, when this file is accessed because 1. the file never gets found by maven and 2. if you try to access it directly ProxiedDavServer fails to recognize it as a metadata file because the check in line 341 compares it to the string "maven-metadata.xml" and fails.
Hide
Christian Domsch added a comment -

This patches the problem with the metadata naming on the server.

Show
Christian Domsch added a comment - This patches the problem with the metadata naming on the server.
Hide
Maria Odea Ching added a comment -

I tried to replicate this in the standalone archiva using the attached settings.xml, and I couldn't replicate the issue. This is my environment:

  • maven 2.0.7/maven-2.0.8
  • ubuntu 7.04
  • jdk 1.5.0_11

I will try deploying Archiva to Geronimo..

Show
Maria Odea Ching added a comment - I tried to replicate this in the standalone archiva using the attached settings.xml, and I couldn't replicate the issue. This is my environment:
  • maven 2.0.7/maven-2.0.8
  • ubuntu 7.04
  • jdk 1.5.0_11
I will try deploying Archiva to Geronimo..
Hide
Christian Domsch added a comment -

As far as I found out, part of the problem seems to be a classloading issue with geronimo. I found out, that when the DefaultRepositoryProxyConnector finished with downloading the maven-metadata-central.xml, it tries to merge it with a possible existing maven-metadata.xml. In this process, the previously downloaded xml is read with a RepositoryMetadataReader, that uses dom4j internally with xpath expressions. This process throws a NoDefClassFoundError while it tries to load org.dom4j.Element. By googling this issue, I found this link:

http://mail-archives.apache.org/mod_mbox/geronimo-user/200705.mbox/%3Ce9f11b850705311735q5e050503s6c29d6c9b968a4e9@mail.gmail.com%3E

I have no clue, what the real problem is in detail, nor how to solve it.

Show
Christian Domsch added a comment - As far as I found out, part of the problem seems to be a classloading issue with geronimo. I found out, that when the DefaultRepositoryProxyConnector finished with downloading the maven-metadata-central.xml, it tries to merge it with a possible existing maven-metadata.xml. In this process, the previously downloaded xml is read with a RepositoryMetadataReader, that uses dom4j internally with xpath expressions. This process throws a NoDefClassFoundError while it tries to load org.dom4j.Element. By googling this issue, I found this link: http://mail-archives.apache.org/mod_mbox/geronimo-user/200705.mbox/%3Ce9f11b850705311735q5e050503s6c29d6c9b968a4e9@mail.gmail.com%3E I have no clue, what the real problem is in detail, nor how to solve it.
Hide
James William Dumay added a comment -

Christian, are you able to reproduce this again and attach your log?

Show
James William Dumay added a comment - Christian, are you able to reproduce this again and attach your log?
Hide
Maria Odea Ching added a comment -

Hi James, I was able to reproduce the plugin download problem in Geronimo. The metadata xml files are all incorrect for the plugins. I've attached the logs and the metadata files.

Show
Maria Odea Ching added a comment - Hi James, I was able to reproduce the plugin download problem in Geronimo. The metadata xml files are all incorrect for the plugins. I've attached the logs and the metadata files.
Hide
Maria Odea Ching added a comment -

Christian, I think the dom4j problem is a different one. I got those errors from the geronimo logs as well (see below), but not from proxying but during the repo scanning..

...
11:00:07,819 ERROR [DatabaseUnprocessedArtifactConsumer:update-db-project] Unable to process model /home/deng/TestFiles/internal/org/codehaus/plexus/plexus-utils/1.0.4/plexus-utils-1.0.4.pom due to : org.dom4j.InvalidXPathException : Invalid XPath expression: '//project'. Caused by: org/dom4j/Element
org.dom4j.InvalidXPathException: Invalid XPath expression: '//project'. Caused by: org/dom4j/Element
at org.dom4j.xpath.DefaultXPath.parse(DefaultXPath.java:362)
at org.dom4j.xpath.DefaultXPath.<init>(DefaultXPath.java:59)
at org.dom4j.DocumentFactory.createXPath(DocumentFactory.java:230)
at org.dom4j.tree.AbstractNode.createXPath(AbstractNode.java:207)
at org.apache.maven.archiva.xml.XMLReader.createXPath(XMLReader.java:175)
at org.apache.maven.archiva.xml.XMLReader.getElement(XMLReader.java:152)
at org.apache.maven.archiva.repository.project.readers.ProjectModel400Reader.read(ProjectModel400Reader.java:80)
at org.apache.maven.archiva.consumers.database.ProjectModelToDatabaseConsumer.processArchivaArtifact(ProjectModelToDatabaseConsumer.java:151)
at org.apache.maven.archiva.database.updater.ProcessArchivaArtifactClosure.execute(ProcessArchivaArtifactClosure.java:52)
at org.apache.commons.collections.CollectionUtils.forAllDo(CollectionUtils.java:388)
at org.apache.maven.archiva.database.updater.JdoDatabaseUpdater.updateUnprocessed(JdoDatabaseUpdater.java:152)
at org.apache.maven.archiva.database.updater.JdoDatabaseUpdater.updateAllUnprocessed(JdoDatabaseUpdater.java:86)
at org.apache.maven.archiva.scheduled.executors.ArchivaDatabaseUpdateTaskExecutor.executeTask(ArchivaDatabaseUpdateTaskExecutor.java:68)
at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116)
at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442)
at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
at java.lang.Thread.run(Thread.java:595)
...

Show
Maria Odea Ching added a comment - Christian, I think the dom4j problem is a different one. I got those errors from the geronimo logs as well (see below), but not from proxying but during the repo scanning.. ... 11:00:07,819 ERROR [DatabaseUnprocessedArtifactConsumer:update-db-project] Unable to process model /home/deng/TestFiles/internal/org/codehaus/plexus/plexus-utils/1.0.4/plexus-utils-1.0.4.pom due to : org.dom4j.InvalidXPathException : Invalid XPath expression: '//project'. Caused by: org/dom4j/Element org.dom4j.InvalidXPathException: Invalid XPath expression: '//project'. Caused by: org/dom4j/Element at org.dom4j.xpath.DefaultXPath.parse(DefaultXPath.java:362) at org.dom4j.xpath.DefaultXPath.<init>(DefaultXPath.java:59) at org.dom4j.DocumentFactory.createXPath(DocumentFactory.java:230) at org.dom4j.tree.AbstractNode.createXPath(AbstractNode.java:207) at org.apache.maven.archiva.xml.XMLReader.createXPath(XMLReader.java:175) at org.apache.maven.archiva.xml.XMLReader.getElement(XMLReader.java:152) at org.apache.maven.archiva.repository.project.readers.ProjectModel400Reader.read(ProjectModel400Reader.java:80) at org.apache.maven.archiva.consumers.database.ProjectModelToDatabaseConsumer.processArchivaArtifact(ProjectModelToDatabaseConsumer.java:151) at org.apache.maven.archiva.database.updater.ProcessArchivaArtifactClosure.execute(ProcessArchivaArtifactClosure.java:52) at org.apache.commons.collections.CollectionUtils.forAllDo(CollectionUtils.java:388) at org.apache.maven.archiva.database.updater.JdoDatabaseUpdater.updateUnprocessed(JdoDatabaseUpdater.java:152) at org.apache.maven.archiva.database.updater.JdoDatabaseUpdater.updateAllUnprocessed(JdoDatabaseUpdater.java:86) at org.apache.maven.archiva.scheduled.executors.ArchivaDatabaseUpdateTaskExecutor.executeTask(ArchivaDatabaseUpdateTaskExecutor.java:68) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:595) ...
Hide
Maria Odea Ching added a comment -

I also found this in the geronimo logs..

14:32:33,558 ERROR [[RepositoryServlet]] Servlet.service() for servlet RepositoryServlet threw exception
org.dom4j.InvalidXPathException: Invalid XPath expression: '//metadata/groupId'. Caused by: org/dom4j/Element
at org.dom4j.xpath.DefaultXPath.parse(DefaultXPath.java:362)
at org.dom4j.xpath.DefaultXPath.<init>(DefaultXPath.java:59)
at org.dom4j.DocumentFactory.createXPath(DocumentFactory.java:230)
at org.dom4j.tree.AbstractNode.createXPath(AbstractNode.java:207)
at org.apache.maven.archiva.xml.XMLReader.createXPath(XMLReader.java:175)
at org.apache.maven.archiva.xml.XMLReader.getElementText(XMLReader.java:258)
at org.apache.maven.archiva.repository.metadata.RepositoryMetadataReader.read(RepositoryMetadataReader.java:56)
at org.apache.maven.archiva.repository.metadata.MetadataTools.readProxyMetadata(MetadataTools.java:360)
at org.apache.maven.archiva.repository.metadata.MetadataTools.updateMetadata(MetadataTools.java:435)
at org.apache.maven.archiva.proxy.DefaultRepositoryProxyConnectors.fetchFromProxies(DefaultRepositoryProxyConnectors.java:367)
at org.apache.maven.archiva.web.repository.ProxiedDavServer.fetchMetadataFromProxies(ProxiedDavServer.java:405)
at org.apache.maven.archiva.web.repository.ProxiedDavServer.fetchContentFromProxies(ProxiedDavServer.java:343)
at org.apache.maven.archiva.web.repository.ProxiedDavServer.process(ProxiedDavServer.java:189)
at org.codehaus.plexus.webdav.servlet.multiplexed.MultiplexedWebDavServlet.service(MultiplexedWebDavServlet.java:119)
at org.apache.maven.archiva.web.repository.RepositoryServlet.service(RepositoryServlet.java:155)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:189)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:39)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.opensymphony.webwork.dispatcher.ActionContextCleanUp.doFilter(ActionContextCleanUp.java:88)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:353)
at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:581)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)

Is this the one you've mentioned above Christian?

Show
Maria Odea Ching added a comment - I also found this in the geronimo logs.. 14:32:33,558 ERROR [[RepositoryServlet]] Servlet.service() for servlet RepositoryServlet threw exception org.dom4j.InvalidXPathException: Invalid XPath expression: '//metadata/groupId'. Caused by: org/dom4j/Element at org.dom4j.xpath.DefaultXPath.parse(DefaultXPath.java:362) at org.dom4j.xpath.DefaultXPath.<init>(DefaultXPath.java:59) at org.dom4j.DocumentFactory.createXPath(DocumentFactory.java:230) at org.dom4j.tree.AbstractNode.createXPath(AbstractNode.java:207) at org.apache.maven.archiva.xml.XMLReader.createXPath(XMLReader.java:175) at org.apache.maven.archiva.xml.XMLReader.getElementText(XMLReader.java:258) at org.apache.maven.archiva.repository.metadata.RepositoryMetadataReader.read(RepositoryMetadataReader.java:56) at org.apache.maven.archiva.repository.metadata.MetadataTools.readProxyMetadata(MetadataTools.java:360) at org.apache.maven.archiva.repository.metadata.MetadataTools.updateMetadata(MetadataTools.java:435) at org.apache.maven.archiva.proxy.DefaultRepositoryProxyConnectors.fetchFromProxies(DefaultRepositoryProxyConnectors.java:367) at org.apache.maven.archiva.web.repository.ProxiedDavServer.fetchMetadataFromProxies(ProxiedDavServer.java:405) at org.apache.maven.archiva.web.repository.ProxiedDavServer.fetchContentFromProxies(ProxiedDavServer.java:343) at org.apache.maven.archiva.web.repository.ProxiedDavServer.process(ProxiedDavServer.java:189) at org.codehaus.plexus.webdav.servlet.multiplexed.MultiplexedWebDavServlet.service(MultiplexedWebDavServlet.java:119) at org.apache.maven.archiva.web.repository.RepositoryServlet.service(RepositoryServlet.java:155) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:189) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:39) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.opensymphony.webwork.dispatcher.ActionContextCleanUp.doFilter(ActionContextCleanUp.java:88) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:353) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:581) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:595) Is this the one you've mentioned above Christian?
Hide
Maria Odea Ching added a comment -

The workaround specified here https://issues.apache.org/jira/browse/GERONIMO-3894 solves this issue Just need to hide the jaxen jar.

Show
Maria Odea Ching added a comment - The workaround specified here https://issues.apache.org/jira/browse/GERONIMO-3894 solves this issue Just need to hide the jaxen jar.
Hide
Maria Odea Ching added a comment -

Could you try it Christian and see if it works for you?
Thanks..

Show
Maria Odea Ching added a comment - Could you try it Christian and see if it works for you? Thanks..
Hide
Christian Domsch added a comment -

Thanxs for all the work so far. As I am pretty busy during this week, I dont know if I find the time to test the workaround. But I will try.

Show
Christian Domsch added a comment - Thanxs for all the work so far. As I am pretty busy during this week, I dont know if I find the time to test the workaround. But I will try.
Hide
Maria Odea Ching added a comment -

I made some comments on the instruction on how to deploy to Geronimo in the wiki:

http://cwiki.apache.org/confluence/display/ARCHIVA/Archiva+on+Geronimo-2.0.2+with+MySQL+backend

Show
Maria Odea Ching added a comment - I made some comments on the instruction on how to deploy to Geronimo in the wiki: http://cwiki.apache.org/confluence/display/ARCHIVA/Archiva+on+Geronimo-2.0.2+with+MySQL+backend

People

Vote (4)
Watch (5)

Dates

  • Created:
    Updated:
    Resolved: