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:[email protected]] Sent: Wednesday, July 11, 2012 9:39 AM To: '[email protected]' 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: [email protected] For additional commands, e-mail: [email protected]
