Issue with artifact in two different repos, but one is corrupted

Sonatype Nexus Repository
1

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.

2

Nexus Repository has a concept of group repositories, so it sounds like both jitpack and camunda-bpm-ee-proxy are in a group, with jitpack first in the order. This means it wins in situations where both underlying repos could serve the same file.

You’ll definitely need your admin to help unless someone else has privileges to expunge the bogus, zero-length POM.

3

Someone did eventually clear out the bogus artifacts from jitpack, but the longer term fix is to better understand the relationship of those two repositories, which your explanation did help me to understand a bit better.