I am a developer in an enterprise that uses Nexus PRO 3.30.0-01 . I don’t maintain it. I’m looking for background on an issue I’m curious about.
A developer working on a Maven project reported an error message like
Checksum validation failed, expected xxxx but is yyyy from nexus for .../zzzz.pom
The project just references this with a typical maven dependency tuple (gav). Our Maven settings.xml file specifies several top-level repositories, and that repository is referenced in the error message. Eliding the actual name, the top-level repository is named “xxx-public-group”.
I looked for this artifact in our internal nexus gui, and I found this artifact in two different “internal” repositories, neither of which is that top-level repository name. The two internal repositories are “jitpack” and “camunda-bpm-ee-proxy”. The artifact in the latter repository looked valid. The artifact in the former repository ONLY had the pom file, and that file was zero length. I also noticed that the expected sha value of the pom file, as specified in the error message, was the same as the one for the “valid” artifact. The actual sha value was the same as the one for the zero length artifact.
It appears there’s a mapping between our “top-level” repositories that we reference in our poms and settings.xml to the “internal” repositories like “jitpack” and “camunda-bpm-ee-proxy”. I’m not familiar with how that works.
I imagine someone in our org who maintains Nexus is going to fix this by deleting (or updating) the artifact in the “jitpack” repository, but I would like to understand more of the background of this problem. I think it’s unlikely you can provide a solution that the impacted developer can utilize without intervention.