NOTE:
I now realize that the jar got placed into my repository, but the pom.xml did not. Now, I have another project where the pom.xml fails to
I have been experiencing the same problem. (TL;DR: solution see last line)
During the deploy from jenkins to Artifactory, sometimes (magic!) a 409 - conflict error appeared with the following error message on the Artifactory log:
[WARN ] (o.a.e.UploadServiceImpl:239) - Sending HTTP error code 409: Checksum policy 'LocalRepoChecksumPolicy: CLIENT' rejected the artifact 'gradle-integration:com.redacted.java/fooProject/123/foo-123.jar'. Checksums info: ChecksumsInfo{checksums={SHA-1=ChecksumInfo{type=SHA-1, original='da39a3ee5e6b4b0d3255bfef95601890afd80709', actual='1459689f0be058f4ecef7e6fe3576f1550a8afda'}, MD5=ChecksumInfo{type=MD5, original='d41d8cd98f00b204e9800998ecf8427e', actual='14c7a498de028d6eb5882b3c698bc456'}}}.
As the trained eye might notice: The MD5# d41d8cd98f00b204e9800998ecf8427e is the checksum for an empty file or string.
Which means that the following must be happening: The copy job that prepares the Artifacts in the publish folder had not finished and therefore the file was empty when the checksum was calculated.
However when the deploy happened the file was there, Artifactory now receives a checksum which is incorrect and correctly refuses the file with the error code 409.
THE SOLUTION (is simple): Make 100% sure the files are definitely there before you start the deploy job (add a pause or proper logic).
I had this issue as well and it turned out that we had include/exclude rules set up on the repository I was trying to deploy to and my deployment didn't match those rules.
My solution was to point the deployment at a new repository that had **/* as the include rule (and the pattern from my other repository as an exclude rule to keep them separate).
I found the problem. Two problems actually:
I only had the release repository setup, and I was attempting to save a snapshot release in the release repository. Artifactory was setup to only allow releases in the release repository. This can be modified in the Artifactory setting, but I decided against this.
My pom.xml
has a different version in it than I was trying to save it to. For example, the pom.xml said version 2.0 and I was trying to save the release as 2.0.2. Artifactory rejected the pom (but not the jar) for this reason.
I found the Artifactory setting (which is per repository) that asks whether or not to "Suppress POM consistency checks". Checking this box will allow me to set the version to one, but have the pom say another.
I also had to modify my Maven "settings.xml" file to allow for both a Release and Snapshot repository. I also have to modify my URL to the snapshot repository.
We were only using Ivy for a while (which doesn't have a snapshot concept), so we were just putting stuff in the release repository. This is a Maven project, and the developer marked the version in the POM as a SNAPSHOT.
Unfortunately, Maven documentation is pretty poor, and there still aren't any good books on Maven. Even worse is that the error messages are simply poor. What does "409, ReasonPhrase:Conflict. -> [Help 1]" mean?
Not that Ivy documentation is so much better, but Ant in Action has some excellent sections on using Ivy.