:main-opts ["-m" "hf.depstar.jar" "yang.jar" "--exclude" "clojure/core/specs/alpha.*"]}

756 Mon Aug 24 20:21:36 EDT 2020 yang/java$map__GT_edn$iter__130__134.class
  3064 Mon Aug 24 20:21:36 EDT 2020 yang/java__init.class
  1316 Mon Aug 24 20:21:36 EDT 2020 yang/java$fn__128.class
  2003 Mon Aug 24 20:21:36 EDT 2020 yang/java$map__GT_edn$iter__130__134$fn__135$fn__136.class
     0 Mon Aug 24 20:23:37 EDT 2020 clojure/
     0 Mon Aug 24 20:23:37 EDT 2020 clojure/core/
     0 Mon Aug 24 20:23:37 EDT 2020 clojure/core/specs/
     0 Mon Aug 24 20:23:37 EDT 2020 tolitius/
  1867 Mon Aug 24 20:21:36 EDT 2020 tolitius/Yang.class

Cool, thanks for testing!

Can I specify version ranges in deps.edn for dependencies?

no

@janne.sauvala Yes, you can, but you shouldn't. The string used for the version in :mvn/version is just passed through to the underlying library, e.g.,

(! 1176)-> clj -Sdeps '{:deps {hiccup {:mvn/version "(,1)"}}}'
DEPRECATED: Libs must be qualified, change hiccup => hiccup/hiccup 
Downloading: hiccup/hiccup/1.0.0-SNAPSHOT/maven-metadata.xml from clojars
Downloading: hiccup/hiccup/1.0.0-SNAPSHOT/hiccup-1.0.0-20120218.070543-1.pom from clojars
Downloading: hiccup/hiccup/1.0.0-SNAPSHOT/hiccup-1.0.0-20120218.070543-1.jar from clojars
Clojure 1.10.1
user=> 

Current version is 1.0.5 but you can get the highest version below that

(! 1177)-> clj -Sdeps '{:deps {hiccup {:mvn/version "(,1.0.5)"}}}'
DEPRECATED: Libs must be qualified, change hiccup => hiccup/hiccup 
Downloading: hiccup/hiccup/maven-metadata.xml from clojars
Downloading: hiccup/hiccup/1.0.4/hiccup-1.0.4.pom from clojars
Downloading: hiccup/hiccup/1.0.4/hiccup-1.0.4.jar from clojars
Clojure 1.10.1
user=> 

^ @vlaaad FYI

it's not actually passed through, it's resolved in canonicalization to the max in range

but a) version ranges have many known weirdnesses and b) as a non-specific version, they also break clj's caching (you will retain the same cached classpath even if newer versions become available)

Interesting to see it works, thanks @seancorfield! I realized I haven’t seen anyone using version ranges so I was wondering were those intentionally not supported

they are officially not supported

but unofficially handled because they exist in the wild, particularly with transitive deps

@alexmiller Good to know re: canonicalization -- I passed in a bad range and the exception came from Aether so I assumed it was just being passed through. My bad:

Unbounded version range (1,
org.eclipse.aether.resolution.VersionRangeResolutionException: Failed to resolve version range for hiccup:hiccup:jar:(1,: Unbounded version range (1,
	at org.apache.maven.repository.internal.DefaultVersionRangeResolver.resolveVersionRange(DefaultVersionRangeResolver.java:137)
	at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveVersionRange(DefaultRepositorySystem.java:247)

> I haven’t seen anyone using version ranges Because they're bad and folks avoid them 🙂

well the resolution happens via aether

I think if you had more of stack, you'd probably see canonicalize in there somewhere