Don't use local Maven repository to detect out of date dependencies

[pmonks]

It appears that antq uses the local Maven repository (e.g. ~/.m2/repository) as part of determining whether an artifact (identified by GAV) is out of date, however this approach leads to false positives when a "temporary development" version of an artifact has been built and installed locally, but is not yet published to any remote repository (e.g. Maven Central or Clojars).

This is a problem because if that dependency is "upgraded" to the local-only version, and then those changes pushed, all other consumers of that code will have dependency resolution errors as that "upgraded" version only exists on that one developer's local storage.

Some Possible Considerations

• Obviously checking all remote repositories for every dependency could be slow - does Maven itself indicate this in its local metadata perhaps, thereby allowing locally built and installed GAVs to be ignored?
• While the current behaviour is problematic for me, it's plausible that other users of antq might be relying on it - perhaps this could/should be controlled by an option flag (with the current behaviour being the default)?

[liquidz]

@pmonks Thanks for your reporting!

this approach leads to false positives when a "temporary development" version of an artifact has been built and installed locally, but is not yet published to any remote repository (e.g. Maven Central or Clojars).

Indeed.

tools.deps requires local repos to create session for now, so I'm not sure yet if I can rule it out, but I'll look into it.
https://github.com/clojure/tools.deps.alpha/blob/dce6bcba266e9261ed671f3f594d7b122f761bf1/src/main/clojure/clojure/tools/deps/alpha/util/maven.clj#L215

[pmonks]

Hopefully Maven stores metadata in the local repository that allows one to distinguish between "remotely sourced" and "locally sourced" organic produce artifacts.

[pmonks]

FYI it looks like Maven does indeed track this. For one of my projects (which is deployed to Clojars, as well as via local installation), I see these two files in the GA directory:

maven-metadata-clojars.xml
maven-metadata-local.xml

The first one lists out the versions of the library that have been deployed to Clojars, while the second lists the ones I installed from a local build.

I assume there are also files for other remotes (such as maven-metadata-central.xml and so forth), but I think you'd only need to avoid versions that only appear in maven-metadata-local.xml (meaning you'd only ever have to worry about the one file, not the myriad other files that exist per-remote).

[liquidz]

@pmonks Thanks for your information!

org.eclipse.aether.RepositorySystem does not seem to tolerate Null as LocalRepository.
So, it might be a good idea to exclude specific versions from version list fetched by Aether in the way you describe :)

[pmonks]

I have zero knowledge of the aether library so there may be a way to do this using it, but for each dependency (GA) couldn't you just parse maven-metadata-local.xml manually (e.g. using clojure.data.xml etc.), and add any version numbers listed there to some kind of "ignore list"?

[liquidz]

@pmonks I've implemented --ignore-locals option to dev branch.
Could you try?

[pmonks]

Looks good here! Thanks!!

And if I'm calling antq.upgrade/upgrade! antq.core/antq programmatically, is the option in the opts arg called :ignore-locals?

[liquidz]

@pmonks Thanks for your confirmation!

And if I'm calling antq.upgrade/upgrade! antq.core/antq programmatically, is the option in the opts arg called :ignore-locals?

Yes, you can use :ignore-locals as a option for antq.core/antq !

[pmonks]

Fantastic! Can't wait to see this released! Thanks again!!

[liquidz]

I'll cut a new release tomorrow at the latest :)