Hi, I have a dependency that suddenly broke. I am using https://clojars.org/amazonica and it results in the following error: Unable to resolve com.amazonaws/amazon-kinesis-client version: [1.7.5, 1.8.0). Any ideas what couldve caused this?

We have had the same issue today, it looks like maven-metadata.xml only has one version available now. https://repo1.maven.org/maven2/com/amazonaws/amazon-kinesis-client/maven-metadata.xml, I have asked about it here - https://github.com/awslabs/amazon-kinesis-client/issues/631 but I'm not sure I am asking the right thing. I fixed temporarily by doing:

wget  
wget 
mvn install:install-file -Dfile=amazon-kinesis-client-1.7.5.jar -DgroupId=com.amazonaws -DartifactId=amazon-kinesis-client -Dversion=1.7.5 -Dpackaging=jar -Dpomfile=amazon-kinesis-client-1.7.5.pom.xm

Is there a way to run clojure -Srepro -Sdeps {,,,} with a flag that prevents it merging the command line deps with a deps.edn file in the working directory?

i.e. an equivalent of Srepro but for the pwd’s deps.edn

No, but I am working on a release right now that may help you. What’s the use case?

Is it running a tool?

Hey… Yes it’s running a clj dev tool we have.

essentially because it merges with deps.edn we end up running into this tdeps issue: https://clojure.atlassian.net/projects/TDEPS/issues/TDEPS-101?filter=allissues&orderby=priority%20DESC&keyword=101 as our deps.edn specifies a :mvn/repos which makes our CI 50s slower than it needs to be

we pull in the tool over a git dep

how might the new release help?

the new feature lets an alias run with isolated rather than merged :deps with the project deps. that's similar but different than what you're wanting

do you want to completely remove the repo or just tweak it?

one thing I did happen to add in latest (not yet released) is the ability to remove a repo by setting it's name to nil

so if that was sufficient you could -Sdeps '{:mvn/repos {"the-server" nil}}'

completely removing would be fine

hmm interesting… that might work

I didn’t think of that

that will fail on current release, but should work on next release, coming. ... hopefully real soon

awesome — is real soon likely to be some time today? or next few days?

no need to promise 🙂

hopefully today, although it sometimes takes a day for the brew pr to make it through

yeah stuff usually takes longer than you think

Anyway, thanks again for this… it’s very timely.

isolated deps would also be useful too — I’ve wanted that from time to time

but instead settled for refactoring stuff out of the core deps into aliases — the problem being the default case then suffers with extra alias baggage

yeah, it is particularly useful for tools

Is there a way to prevent tools-deps to download maven-metadata.xml files?

currently, no.

are you looking for an "offline" mode?

if you already have needed versions locally, I'm actually not sure off the top of my head whether it will make any remote calls.

It is because of the https://github.com/awslabs/amazon-kinesis-client/issues/631

yeah, I don't think there's any way to do explicitly that right now

I am using amazonica in deps.edn and explicitly exclusions the kinisis-client-library. It all worked until today that is. The annoying thing is that I do not even want to use the kinesis-client-library.

exclusions work on the library level, not version level. is it just running into trying to get an older version to do the check?

Snippet of deps.edn:

com.amazonaws/aws-java-sdk-core    {:mvn/version "1.11.521"}
  com.amazonaws/aws-java-sdk-sts     {:mvn/version "1.11.521"}
  com.amazonaws/aws-java-sdk-s3      {:mvn/version "1.11.521"}
  amazonica                          {:mvn/version "0.3.140"
                                      :exclusions
                                      [com.amazonaws/aws-java-sdk
                                       com.amazonaws/amazon-kinesis-client]}

yeah, I was more wondering how it manifests in a clj failure?

% clj -Stree                                                                     
Error building classpath. Unable to resolve com.amazonaws/amazon-kinesis-client version: [1.7.5, 1.8.0)

I'm guessing amazonica relies on some particular older version and it's trying to find that, before it gets to the point of checking exclusions

yeah

So something thinks that it should find [1.7.5, 1.8.0) and then later it is excluded anyway.

yeah

if you're just looking for a temporary workaround, you may be able to add it at the top level, with the version that's available, and exclude it there too

com.amazonaws/amazon-kinesis-client {:mvn/version "1.12.0" :exclusions [com.amazonaws/amazon-kinesis-client]}

That looks really silly but let me try it 🙂

nah, exclusions works only on children

so won't work

this will work...

clj -Sdeps '{:aliases {:x {:override-deps {com.amazonaws/amazon-kinesis-client {:mvn/version "1.12.0"}}}}}' -A:x

basically supply an alias that overrides the version to use to the one that happens to be available

actually, never mind, you'll still hit this

Sadly no

have you checked any of hte maven mirrors?

Not yet

But I guess these mirrors will be updated to central at a certain moment, as they are mirrors.

maybe

Or does each mirror keeps their owne maven-metadata

http://uk.maven.org/maven2/com/amazonaws/amazon-kinesis-client/ seems to have them

oh, not in metadata though

the google mirror seems to have them https://maven-central.storage-download.googleapis.com/repos/central/data/com/amazonaws/amazon-kinesis-client/maven-metadata.xml

so you could try adding {:mvn/repos {"central" {:url ""}}}

that doesn't seem to work for me, but I'm not sure why

Thanks. That will probably work (until it gets hit by 1.12.0 as well)

oh, that works if I rm the amazon-kinesis-client out of my ~/.m2 (it caches that source metadata)

maven central uploads have been giving me many weird errors over the last 24 hrs

might be something is awry there and an indexing job failed

did you file a ticket with sonatype?

I have an acct there already and I can do so if needed

It would be great if you filed a ticket there.

our CI (travis) has .m2 cached… but it seems that running clojure for the first time on a single private git/dep in each build container refetches these deps each time:

Downloading: org/clojure/clojure/1.10.0/clojure-1.10.0.pom from 
Checking out: [email protected]:Swirrl/omni.git at 7570a53fdbb1d72aabac13ab25e1172ced808eb8
Downloading: hiccup/hiccup/1.0.5/hiccup-1.0.5.pom from 
Downloading: org/clojure/clojure/1.10.0/clojure-1.10.0.jar from 
Downloading: org/apache/commons/commons-lang3/3.5/commons-lang3-3.5.jar from 
Downloading: commons-io/commons-io/2.5/commons-io-2.5.jar from 
Downloading: org/ow2/asm/asm/5.0.3/asm-5.0.3.jar from 
Downloading: hiccup/hiccup/1.0.5/hiccup-1.0.5.jar from 

I don’t know where they’re coming from… as hiccup is not a dependency of omni; and they already exist in .m2

so it looks like tools.deps is refetching them

I can't really do anything without more info. need 1) deps.edn and 2) output of clj -Stree -Sdeps '{:aliases {:v {:verbose true}}}' -A:v