Issue with broken packages if repository doesn't resolve properly

Question

My project edn had a old maven link that no longer resolves, since maven switched to https only in 2020:

:mvn/repos {"central" {:url "http://central.maven.org/maven2/"}

When retrieving deps from a new computer, the packages were all failing with errors like:

Downloading: selmer/selmer/1.12.31/selmer-1.12.31.pom from central
Download corrupted: Checksum validation failed, expected <meta but is ad208edec82716369dab76b6cbca3475a4ae2033

This was because the downloaded "package" were instead HTML files due to AT&T dnsassist.

Since the checksum fails, I would expect the package downloaded to be deleted instead of kept as it is (broken html files). I had to delete the entire .m2, fix the repo link, and then redownload to fix.

Answer 1

I looked into this a bit more and normally an invalid url (like http central url) will fail with an UnknownHostException and not download anything. While it's not super pretty, I think it's pretty clear what fails in this case.

The behavior you received with dnsassist is that it looks like the dns is redirected to an html page. I don't know a lot about dnsassist but it sounds pretty questionable to me. In this case, from Maven's perspective, it is asking for content at a url and getting some back, which it saves in a file. The checksum system is working as designed - there should be a file X and a checksum file X.asc and the latter should contain the checksum of the former file's contents. Because of dnsassist, this does not hold and an error is reported. As a user of the Maven libs, tools.deps/clj does not really have any control over it other than printing the results, so I do not see anything that we can actively do in this case other than what we're doing.