This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # 100-days-of-code (6)
- # announcements (4)
- # aws (2)
- # beginners (151)
- # boot (1)
- # calva (1)
- # cider (19)
- # clara (47)
- # cljdoc (9)
- # cljs-dev (25)
- # clojars (18)
- # clojure (151)
- # clojure-canada (1)
- # clojure-conj (1)
- # clojure-dev (17)
- # clojure-italy (42)
- # clojure-nl (34)
- # clojure-spec (67)
- # clojure-uk (125)
- # clojurescript (163)
- # core-async (106)
- # cursive (19)
- # data-science (11)
- # datomic (9)
- # duct (2)
- # figwheel (1)
- # figwheel-main (6)
- # fulcro (97)
- # graphql (9)
- # instaparse (4)
- # jobs (6)
- # jobs-discuss (21)
- # leiningen (62)
- # mount (23)
- # off-topic (16)
- # re-frame (15)
- # reagent (16)
- # reitit (5)
- # remote-jobs (1)
- # ring-swagger (9)
- # shadow-cljs (176)
- # tools-deps (102)
- # unrepl (3)
lein repl started hanging for me for some reason, it just doesn't do anything anymore, no error, nothing... ->
Leiningen 2.8.1 on Java 1.8.0_192 OpenJDK 64-Bit Server VM
Any idea why that might be?
I found it, was a custom artifactory which was not reachable anymore, still not the best way to handle that I suppose 😞
lein is warning me about version ranges being used by a dependency of mine. How can I resolve this, since I have no control over that dependency’s usage of version ranges?
You might be able to exclude your dependency’s dependency, and then manually add a version that you have control over.
My case also seems to be an instance of this: https://github.com/technomancy/leiningen/issues/2251. Where the version range being declared by my dependency is actually a single version and they are doing it that way to guarantee that version.
I’m not sure how I feel about taking that control from the dependency. There must have been a reason for it. But it seems like there’s no other way to get rid of the warning, which is very noisy
:dependencies [ ... [org.apache.beam/beam-runners-google-cloud-dataflow-java "2.7.0" :exclusions [[io.grpc/grpc-core] [io.grpc/grpc-netty]]] ... :managed-dependencies [[grpc-core "1.2.0"] [io.grpc/grpc-netty "1.13.1"]]
you shouldn’t even need an exclusion for a transitive dep if you explicitly declare it
I wasn’t thinking of
:managed-dependencies (which I hadn’t heard of before), but you might want to try just including the dependencies you need like mikerod says. If that doesn’t work, try adding the exclusion, and if that also fails, try the :managed-dependencies.
putting things in
:managed-dependencies alone doesn’t add any real dep to the project I believe
I still get warnings if I use
:exclusions as above. If I try to declare it in
:dependencies, I get an error that the artifact couldn’t be found in maven or clojars.
@mikerod: The warnings only go away if I do the
:exclusions. Adding the direct dependencies has no effect
it doesn’t seem like a good idea to exclude transitive deps without knowing what they are there for
Well, I excluded them, but I also declared them as direct dependencies of mine. So shouldn’t that address your concern?
yes, that works, I’m surprised you have to exclude them at all though to get rid of warning, but that’s possible if lein generates those at the wrong time I guess
so if it warning you about a dep’s dep that you already have overridden, that’d be superfluous warnings
hmm, well I had the impression version ranges supercede all other dependency resolution mechanisms.
I got that impression from this I guess:
In addition, version ranges introduce unexpected quirks in the dependency resolution process due to their surprising semantics around precedence; it's recommended that you avoid them entirely.
> Aether lets version ranges take priority over normal “soft” dependencies, and the project uses 1.5.0-alpha2 instead. Normally a direct dependency will take priority over any transitive dependencies. This situation causes a surprise for the user, who would not be expecting a transitive version range. The user has to go explicitly add an :exclusion to get the desired version of clojure. never heard that on aether
(If there is another way to generate the code from the wsdl without maven im totally on board too. The maven was just the first answer I found)
The other step would need mvn installed to run, but you could use something like the lein-shell plugin to shell out to Maven after the Pom is generated.
Could get that all happening with a lein
:aliases entry and could get it done as
:prep-tasks for some profile for other lein tasks that depended on it