Artifactory ignores checksum uploads on maven-metadata.xml files

Question

I have a large Maven repository, hosted by Artifactory version 5.4.6. Using the JFrog REST API, I can look at all the bad or missing checksums with

curl -u "admin:$PASSWORD" -X GET "http://myserver/artifactory/api/search/badChecksum?type=sha1&repos=mymavenrepo"

This returns surprisingly a lot of errors about "missing client checksums" for all my "maven-metadata.xml" files.

However I deploy all the files in the repo using maven plugins that do publish checksums. And when I deploy new files, I can see in logs/request.log that

the existing maven-metadata.xml is downloaded (GET on maven-metadata.xml)
the updated maven-metadata.xml is uploaded (PUT on maven-metadata.xml)
the MD5 hash for the updated maven-metadata.xml is uploaded (PUT on maven-metadata.xml.md5)
the SHA1 hash for the updated maven-metadata.xml is uploaded (PUT on maven-metadata.xml.sha1)

Doing some tests on the CLI, I can confirm that PUT calls to set checksums work on normal files, but are simply ignored on maven-metadata.xml files.

For a standard JAR

FAKE_SHA1=0000111122223333444455556666777788889999
curl -u "admin:$PASSWORD" -X PUT "http://myserver/artifactory/mymavenrepo/javax/mail/mail/1.4.3/mail-1.4.3.jar.sha1" --data-ascii "$FAKE_SHA1"

will return the following errors

{
  "errors" : [ {
    "status" : 409,
    "message" : "Checksum error for 'javax/mail/mail/1.4.3/mail-1.4.3.jar.sha1': received '0000111122223333444455556666777788889999' but actual is '8154bf8d666e6db154c548dc31a8d512c273f5ee'"
  } ]
}

For a maven-metada.xml file

FAKE_SHA1=0000111122223333444455556666777788889999
curl -u "admin:$PASSWORD" -X PUT "http://myserver/artifactory/mymavenrepo/javax/mail/mail/maven-metadata.xml.sha1" --data-ascii "$FAKE_SHA1"

will return absolutely nothing

And now, launching badChecksum will complain that the JAR has a wrong client checksum, but will keep complaining that the maven metadata has no client checksum:

curl -u "admin:$PASSWORD" -X GET "http://myserver/artifactory/api/search/badChecksum?type=sha1&repos=mymavenrepo" | grep "javax/mail" -A2

returns

    "uri" : "http://myserver/artifactory/api/storage/mymavenrepo/javax/mail/mail/maven-metadata.xml",
    "serverSha1" : "61001c349ebaac8e116d5f25716e2abf31e081af",
    "clientSha1" : ""
--
    "uri" : "http://myserver/artifactory/api/storage/mymavenrepo/javax/mail/mail/1.4.3/mail-1.4.3.jar",
    "serverSha1" : "8154bf8d666e6db154c548dc31a8d512c273f5ee",
    "clientSha1" : "0000111122223333444455556666777788889999"

Is there any reason for maven-metadata.xml files to have weird checksum semantics? This basically breaks the badChecksum REST feature for me, as legitimate errors are flooded by these metadata errors.

My point of view is that either maven-metadata.xml files are special and badChecksum should ignore them, or they act like normal files, and client checksums should be recorded...

The only workaround I see is to use the fixChecksum API but then you simply accept the server checksum rather than push the local checksum...

curl -u "admin:$PASSWORD" -X POST "http://myserver/artifactory/api/checksums/fix" --data-ascii "{\"repoKey\":\"mymavenrepo\",\"path\":\"javax/mail/mail/maven-metadata.xml\"}" --header "Content-Type: application/json"
{"info":"Successfully fixed checksum inconsistency"}

I would be happy to get a comment explaining the downvote. I think missing client checksums is annoying for a lot of people. If I am missing something obvious, I would like to know... — Arnaud Jeansen
maven-metadata.xml is auto-generated by Artifactory based on the contents of adjacent folders, why do you want to set checksums for it..? — danf
if you are using the maven command line to deploy artifacts, maven will itself download the existing maven-metadata.xml and reupload it afterwards. AFAICS, this logic is in the org.eclipse.aether.internal.impl.DefaultDeployer class in maven-artifact-transfer. You can do the following test from a standard maven project: mvn clean install deploy:deploy -DaltDeploymentRepository=test::default::http://myserver/artifactory/mymavenrepo You will see in the logs that the deploy plugin downloads the metadata first, and reuploads it last. — Arnaud Jeansen

susanoobit susanoobit · Accepted Answer · 2018-09-11T17:43:31

I have a similar problem in Intellij when I try to publish modules to a Maven repository, hosted by Artifactory, using the JFrog REST API. The problem is: apparently (by what the logs say), the regular Deploy Apache Maven Plugin sends a file .sh1 or .md5 along with the module, e.g., a .jar file, but the JFrog REST API expects a HTTP header with the sha1 or md5 value, not a file.

The solution I found: using the Maven Artifactory Plugin. It deals with this part (apparently it deals, because the error has gone, but I didn't look whats is going on under the hood).

Artifactory ignores checksum uploads on maven-metadata.xml files

1 Answers