You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by "Pimentel, Robert" <Ro...@tgslc.org> on 2012/07/11 16:38:59 UTC
Corrupt metadata
Maven 2.2.1
Archiva 1.2.1
Hudson 2.0.0
Hi,
It appears that we have a corrupt metadata file for one of our projects. Here is a snippet of the output from the failing job:
[WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = 'cd315359376ec31bb4e3213a368618ecc7beca1e'; remote = '8de5987a48151f2d923dda8dd28797d07c15d4d6' - RETRYING
[WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = 'cd315359376ec31bb4e3213a368618ecc7beca1e'; remote = '8de5987a48151f2d923dda8dd28797d07c15d4d6' - IGNORING
...
...
...
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error installing artifact's metadata: Error installing metadata: Error updating group repository metadata
in epilog non whitespace content is not allowed but got 4 (position: END_TAG seen ...</metadata>\n4... @16:2)
I checked <Archiva_snapshots_folder>\<groupID>\maven-metadata.xml for that project on the server hosting Archiva, and confirmed the xml is malformed (per the line number in the error). If I look at the maven repo on the build machine (different server) for that project, I can see that maven-metadata-local.xml is valid. However, maven-metadata-snapshots.xml on the Archiva server is identical (malformed) to maven-metadata.xml. I am guessing the build machine does a checksum on <Archiva_snapshots_folder>\<groupID>\maven-metadata.xml and compares it to the contents of <Archiva_snapshots_folder>\<groupID>\maven-metadata.xml.sha1. There's a warning that the hash values don't match, and then it appears to ignore that fact. I checked settings.xml, nothing for checksum policy for snapshots repo. I checked our org pom and the checksum policy is set to warn for the snapshots repo, so I presume the job output resembles that policy. Shortly after that, the job fails when it attempts to install the artifact's metadata (into the maven repository on the build machine? -not sure what this step tries to do).
1) Is it considered best practice to switch checksum behavior to fail..even for snapshots repositories? Please elaborate if you can.
2) Should I simply delete <Archiva_snapshots_folder>\<groupID>\maven-metadata.xml? Will it get automatically recreated? Do I need to run Update Consumers (validate-repository-metadata Verify repository metadata files against database) in Archiva?
3) Any good documentation on maven metadata, and how local maven repo files are updated versus those on the MRM machine? I found this http://docs.codehaus.org/display/MAVEN/Repository+Metadata, but I would like to know how the files are used/referenced in the different phases of the default lifecycle.
Thanks,
Rob
RE: Corrupt metadata
Posted by "Pimentel, Robert" <Ro...@tgslc.org>.
Regarding #2, I renamed the file to .old, re-ran the job, and it recreated maven-metadata.xml with the appropriate information.
-----Original Message-----
From: Pimentel, Robert [mailto:Robert.Pimentel@tgslc.org]
Sent: Wednesday, July 11, 2012 9:39 AM
To: 'users@maven.apache.org'
Subject: Corrupt metadata
Maven 2.2.1
Archiva 1.2.1
Hudson 2.0.0
Hi,
It appears that we have a corrupt metadata file for one of our projects. Here is a snippet of the output from the failing job:
[WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = 'cd315359376ec31bb4e3213a368618ecc7beca1e'; remote = '8de5987a48151f2d923dda8dd28797d07c15d4d6' - RETRYING
[WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = 'cd315359376ec31bb4e3213a368618ecc7beca1e'; remote = '8de5987a48151f2d923dda8dd28797d07c15d4d6' - IGNORING
...
...
...
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error installing artifact's metadata: Error installing metadata: Error updating group repository metadata
in epilog non whitespace content is not allowed but got 4 (position: END_TAG seen ...</metadata>\n4... @16:2)
I checked <Archiva_snapshots_folder>\<groupID>\maven-metadata.xml for that project on the server hosting Archiva, and confirmed the xml is malformed (per the line number in the error). If I look at the maven repo on the build machine (different server) for that project, I can see that maven-metadata-local.xml is valid. However, maven-metadata-snapshots.xml on the Archiva server is identical (malformed) to maven-metadata.xml. I am guessing the build machine does a checksum on <Archiva_snapshots_folder>\<groupID>\maven-metadata.xml and compares it to the contents of <Archiva_snapshots_folder>\<groupID>\maven-metadata.xml.sha1. There's a warning that the hash values don't match, and then it appears to ignore that fact. I checked settings.xml, nothing for checksum policy for snapshots repo. I checked our org pom and the checksum policy is set to warn for the snapshots repo, so I presume the job output resembles that policy. Shortly after that, the job fails when it attempts to install the artifact's metadata (into the maven repository on the build machine? -not sure what this step tries to do).
1) Is it considered best practice to switch checksum behavior to fail..even for snapshots repositories? Please elaborate if you can.
2) Should I simply delete <Archiva_snapshots_folder>\<groupID>\maven-metadata.xml? Will it get automatically recreated? Do I need to run Update Consumers (validate-repository-metadata Verify repository metadata files against database) in Archiva?
3) Any good documentation on maven metadata, and how local maven repo files are updated versus those on the MRM machine? I found this http://docs.codehaus.org/display/MAVEN/Repository+Metadata, but I would like to know how the files are used/referenced in the different phases of the default lifecycle.
Thanks,
Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org