This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-07-29
Channels
- # aleph (3)
- # announcements (16)
- # beginners (85)
- # calva (2)
- # cider (13)
- # clj-kondo (84)
- # cljdoc (3)
- # clojure (109)
- # clojure-belgium (1)
- # clojure-china (39)
- # clojure-europe (4)
- # clojure-france (1)
- # clojure-italy (70)
- # clojure-nl (8)
- # clojure-spec (8)
- # clojure-uk (53)
- # clojuredesign-podcast (14)
- # clojurescript (43)
- # cursive (25)
- # data-science (1)
- # datomic (4)
- # emacs (10)
- # figwheel (4)
- # garden (4)
- # graphql (5)
- # jackdaw (10)
- # jobs (5)
- # jobs-discuss (5)
- # lambdaisland (2)
- # leiningen (3)
- # luminus (7)
- # off-topic (32)
- # pathom (11)
- # pedestal (2)
- # planck (15)
- # re-frame (12)
- # reagent (4)
- # remote-jobs (2)
- # shadow-cljs (51)
- # sql (29)
- # tools-deps (47)
@dominicm good to know that doesn't work yet - if it did, that would be a reason for me to jump from boot to tools.deps in our local codebase, since we have locally shared deps now that we must deploy somewhere, which feels a bit icky
as TDEPS-132 indicates, I consider this out of scope for now, no plans to work on that
is there something in tools.deps which combines R and C? so I want all test deps but also the test dir to be on the classpath
yes, if there is one in the test alias. you didn't mention that
if that's the case, then I'd say no, use -R and -C
well, I only know after looking, so it's not something I would use by default that way
Every time I run clj
in some of my projects, I get all of this outputted:
Downloading: io/grpc/grpc-core/maven-metadata.xml from
Downloading: io/grpc/grpc-api/maven-metadata.xml from
Downloading: io/grpc/grpc-core/maven-metadata.xml from
Downloading: io/grpc/grpc-api/maven-metadata.xml from
Downloading: io/grpc/grpc-api/maven-metadata.xml from
Downloading: io/grpc/grpc-core/maven-metadata.xml from
Downloading: io/grpc/grpc-core/maven-metadata.xml from
Downloading: io/grpc/grpc-netty-shaded/maven-metadata.xml from
Downloading: io/grpc/grpc-core/maven-metadata.xml from
Downloading: io/grpc/grpc-api/maven-metadata.xml from
Downloading: io/grpc/grpc-api/maven-metadata.xml from
Downloading: io/grpc/grpc-core/maven-metadata.xml from
Downloading: io/grpc/grpc-api/maven-metadata.xml from
Is this necessary?@kenny That indicates you are either depending on SNAPSHOT releases or RELEASE/LATEST rather than specific non-snapshot versions.
Since snapshots and both RELEASE/LATEST can refer to different versions over time, the dependency checker must fetch metadata to check which version is current.
Yeah, I would expect it to show up in -Stree
Well, something is trying to pull in io.grpc/grpc-core
and/or io.grpc/grpc-api
...
-Stree
shows what version it is resolved to -- not necessarily how it was declared.
So using the output of -Stree
you can figure out what path through the dependencies was taken -- and then look in your deps.edn
to see how you're pulling those top-level things in...
Well it's from this dep: com.google.cloud/google-cloud-monitoring {:mvn/version "1.78.0"}
I don't see it here: https://repo1.maven.org/maven2/com/google/cloud/google-cloud-monitoring/1.78.0/google-cloud-monitoring-1.78.0.pom
That specifies dependencies with no versions https://search.maven.org/artifact/com.google.cloud/google-cloud-monitoring/1.78.0/jar
So because they didn't specify a version, tools-deps tries to find the latest one each time?
Because they're Google? You can probably fix that by putting those dependencies explicitly in your project with appropriate versions...
Ah, looks like they specify them in the parent pom https://search.maven.org/artifact/com.google.cloud/google-cloud-clients/0.96.0-alpha/pom
So maybe tools.deps
doesn't follow that path? @alexmiller might be able to speak to that.
But at least that gives the specific versions you'd be expected to use (with GCM 1.78.0)
Is a parent supposed to be included in the dep tree or only used to resolve artifacts in the child?
(look at the <properties>
section of that parent pom I linked to)
That question is beyond my Maven knowledge, sorry.
in the clj
repl?
Right, because it resolves all the versions.
I'm just suggesting you can suppress those metadata fetches by explicitly declaring dependencies in deps.edn
on the relevant versions of io.grpc/grpc-core
, io.grpc/grpc-api
, etc.
I have a bunch of dev-only tooling where I use RELEASE as the version and every day clj
will show messages about fetching metadata -- to check the most recent version.
In your -Stree
output, what version of those io.grpc
libs does it show that it resolves to?
Makes sense. The latest GCM's parent pom still uses that version too. https://search.maven.org/artifact/com.google.cloud/google-cloud-clients/0.102.0-alpha/pom
Yup. That's what I'd expect.