CODEWITHSUNDEEP
maven-3artifactory
Arnaud Jeansen
Arnaud Jeansen

Reputation: 1726

Artifactory ignores checksum uploads on maven-metadata.xml files

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

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"}

Upvotes: 3

Views: 2772

Answers (1)

susanoobit
susanoobit

Reputation: 128

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).

Upvotes: 2

Related Questions