Archiva

Archiva don't want to download a snapshot of a maven plugin (merged metadata are empty)

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Blocker Blocker
  • Resolution: Fixed
  • Affects Version/s: 1.1.1, 1.1.3, 1.2-M1, 1.2
  • Fix Version/s: 1.2
  • Component/s: remote proxy
  • Labels:
    None
  • Environment:
    I have the problem in production (Linux + archiva 1.1.1)
    I reproduced it on my laptop (XP with archiva 1.1.1, 1.1.3, 1.2-M1 and trunk)
  • Testcase included:
    yes
  • Number of attachments :
    4

Description

Use case :

  • I want to use idl-maven-plugin 1.1-SNPASHOt from codehaus
  • In archiva I have a group (snapshots) with behind a managed repository (snapshots-proxy) which proxify http://snapshots.repository.codehaus.org/
  • When I launch the build of the project, archiva download metadata for 1.1-SNAPSHOT from codehaus in maven-metadata-codehaus-snapshots.xml which is fine
  • But it creates an empty maven-metadata.xml
  • Maven receive this empty file and try to download 1.1-SNAPSHOT artifacts instead of the last timestamp.

I attach :

  • A minimal project which uses a local archiva
  • The achiva config file (be careful to deactivate/change the network proxy)
  • maven-metadata-codehaus-snapshots.xml and maven-metadata.xml

Attachments

  1. XML File
    archiva.xml
    11/Mar/09 12:51 PM
    6 kB
    Arnaud Heritier
  2. XML File
    maven-metadata.xml
    11/Mar/09 12:51 PM
    0.1 kB
    Arnaud Heritier
  3. XML File
    maven-metadata-codehaus-snapshots.xml
    11/Mar/09 12:51 PM
    0.6 kB
    Arnaud Heritier
  4. XML File
    pom.xml
    11/Mar/09 12:51 PM
    2 kB
    Arnaud Heritier

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Arnaud Heritier added a comment -

This morning I noticed that archiva has a maven-metadata.xml which is my yesterday's maven-metadata-codehaus-snapshots.xml
And my maven-metadata-codehaus-snapshots.xml is updated from the one in codehaus repo.
There's a problem of sync between the main maven-metadata.xml and the remote one (maven-metadata-codehaus-snapshots.xml)
I didn't have a look at the code but I think that the merge process isn't call after having update a remote copy...

Show
Arnaud Heritier added a comment - This morning I noticed that archiva has a maven-metadata.xml which is my yesterday's maven-metadata-codehaus-snapshots.xml And my maven-metadata-codehaus-snapshots.xml is updated from the one in codehaus repo. There's a problem of sync between the main maven-metadata.xml and the remote one (maven-metadata-codehaus-snapshots.xml) I didn't have a look at the code but I think that the merge process isn't call after having update a remote copy...
Hide
Permalink
Maria Odea Ching added a comment -

This also happens even without a repository group configured.

Show
Maria Odea Ching added a comment - This also happens even without a repository group configured.
Hide
Permalink
Maria Odea Ching added a comment -

I've traced the problem to be at the XMLReader when the contents of the proxied metadata (maven-metadata-codehaus-snapshots.xml) is retrieved. The nodes are returning 'null' even if the xpath expression seems correct.

Show
Maria Odea Ching added a comment - I've traced the problem to be at the XMLReader when the contents of the proxied metadata (maven-metadata-codehaus-snapshots.xml) is retrieved. The nodes are returning 'null' even if the xpath expression seems correct.
Hide
Permalink
Maria Odea Ching added a comment - - edited

It seems that the following attributes of the <metadata> tag is what's causing the nodes not to be retrieved. When I removed them from the sample metadata file I was using in the test case, I was able to retrieve the child nodes with the correct values.

xsi:schemaLocation="http://maven.apache.org/METADATA/1.0.0 http://maven.apache.org/xsd/metadata-1.0.0.xsd" xmlns="http://maven.apache.org/METADATA/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

Show
Maria Odea Ching added a comment - - edited It seems that the following attributes of the <metadata> tag is what's causing the nodes not to be retrieved. When I removed them from the sample metadata file I was using in the test case, I was able to retrieve the child nodes with the correct values. xsi:schemaLocation="http://maven.apache.org/METADATA/1.0.0 http://maven.apache.org/xsd/metadata-1.0.0.xsd" xmlns="http://maven.apache.org/METADATA/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
Hide
Permalink
Maria Odea Ching added a comment -

Fixed in trunk -r756559.

Show
Maria Odea Ching added a comment - Fixed in trunk -r756559.
Hide
Permalink
Arnaud Heritier added a comment -

I probably deployed this snapshot with maven 2.1.0. Brett is investigating why metadata have this schema now.
This could explains why it occurs with many archiva versions but that we didn't see this error before.

Show
Arnaud Heritier added a comment - I probably deployed this snapshot with maven 2.1.0. Brett is investigating why metadata have this schema now. This could explains why it occurs with many archiva versions but that we didn't see this error before.
Hide
Permalink
Maria Odea Ching added a comment -

Ok, thanks for all the input Arnaud
As for the fix in -r756559, I first cleared out the namespaces in the document object before retrieving the child nodes of the metadata element.

Show
Maria Odea Ching added a comment - Ok, thanks for all the input Arnaud As for the fix in -r756559, I first cleared out the namespaces in the document object before retrieving the child nodes of the metadata element.
Hide
Permalink
Arnaud Heritier added a comment -

Do you think we could backport this change in 1.1.X ? All our 1.1.x will have this issue each time someone will deploy an artifact with maven 2.1

Show
Arnaud Heritier added a comment - Do you think we could backport this change in 1.1.X ? All our 1.1.x will have this issue each time someone will deploy an artifact with maven 2.1
Hide
Permalink
Maria Odea Ching added a comment -

Yeah, I think we should. I've opened MRM-1152 to track it for 1.1.x

Show
Maria Odea Ching added a comment - Yeah, I think we should. I've opened MRM-1152 to track it for 1.1.x

People

Vote (5)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.