Upgrade should follow Maven relocations

[pmonks]

Steps to reproduce:

1. In an empty directory, create a deps.edn file with this content:

{:deps {mysql/mysql-connector-java {:mvn/version "8.0.30"}}
 :aliases {:outdated {
             :deps {com.github.liquidz/antq {:mvn/version "RELEASE"}}
             :main-opts ["-m" "antq.core"]}}}

2. Run clj- P and observe that it successfully downloads the referenced library
3. Run clj -A:outdated and observe that the dependency is out of date (at the time of writing, the latest version is 8.0.33)
4. Run clj -A:outdated --upgrade --force

Expected result:
The dependency's GAV in the deps.edn file is modified from mysql/mysql-connector-java {:mvn/version "8.0.30"} to com.mysql/mysql-connector-j {:mvn/version "8.0.33"}, since the pom.xml for mysql/mysql-connector-java {:mvn/version "8.0.33"} contains this relocation information:

  <distributionManagement>
    <relocation>
      <groupId>com.mysql</groupId>
      <artifactId>mysql-connector-j</artifactId>
      <message>MySQL Connector/J artifacts moved to reverse-DNS compliant Maven 2+ coordinates.</message>
    </relocation>
  </distributionManagement>

Actual result:
The dependency's GAV in the deps.edn file only has its version updated (to 8.0.33), which will then fail when downloaded (e.g. via clj -P) since there is no Maven artifact for mysql/mysql-connector-java {:mvn/version "8.0.33"} (due to the relocation).

[liquidz]

@pmonks Thank you for your reporting!

It is impossible to know which versions have relocation unless we check.
Therefore, we would need to check for the existence of relocation for all outdated dependencies, but it seems to be quite wasteful.

I'm planning to implement it initially as an optional feature, and then continue to search for a more efficient way of checking.

[pmonks]

No worries! It was actually another Clojure user who pointed this out to me, though I don't know their GitHub handle to @mention them. Regardless they deserve the credit!

Given that upgrades break a previously functional build when a relocation is present, I think the performance cost of checking for them is probably the lesser of two evils (especially as I suspect that cost isn't very high per outdated dependency).

[liquidz]

@pmonks

Given that upgrades break a previously functional build when a relocation is present, I think the performance cost of checking for them is probably the lesser of two evils (especially as I suspect that cost isn't very high per outdated dependency).

You are right.
For now, I've tried to always check.
Could you try feature/relocation branch?

[pmonks]

I'm sorry but I haven't had the opportunity to try that branch, and probably won't for the foreseeable future. Perhaps it could be placed behind a command line flag and released, so that the wider community can help test it?