Fork me on GitHub

when try to uberjar, meet this error

Caused by: org.eclipse.aether.resolution.ArtifactResolutionException: Could not find artifact org.quartz-scheduler:quartz-parent:pom:2.3.0 in terracotta-snapshots ()
This dependency, will be handled correct when using leiningen. I don't know how to investigate the issue, where should I start?


This looks like TDEPS-50 also?


Is there a tools.deps friendly way to run Eastwood from the command line?


Also, what is a no-fuss way to build an uberjar for a deps.edn project? I tried pack.alpha, depstar so far and I get weird errors.


depstar: I get this issue:, too much fuss to do manifests etc.



NOTE: /alpha/bootstrap/onejar/src/com/simontuffs/onejar/, line -1: Some input files use unchecked or unsafe operations.

NOTE: /alpha/bootstrap/onejar/src/com/simontuffs/onejar/, line -1: Recompile with -Xlint:unchecked for details.

~/d/n/c/october (master|✚1…) $ java -jar output.jar
Exception in thread "main" java.lang.ClassNotFoundException: clojure.main
	at com.simontuffs.onejar.JarClassLoader.findClass(
	at java.lang.ClassLoader.loadClass(
	at com.simontuffs.onejar.JarClassLoader.loadClass(
	at java.lang.ClassLoader.loadClass(
	at com.simontuffs.onejar.Boot.main(


@orestis For pack.alpha, that seems to indicate it didn't include the Clojure runtime -- no idea about that since I haven't tried it but @U09LZR36F (the author) is very helpful. For depstar, adding the manifest manually is an easy step and I like the raw simplicity of it. Haven't tried cambada so thanks for finding that and posting the link!


It’s up on the tools.deps wiki and has a very good README :)


Yeah, just looking it over. Very nice!


I think the pack bug would be fixed by using the latest version.


I haven't updated the installer, and I should!


Hooray - seems to work out of the box, with the only addition being an extra command-line parameter to specify the main namespace


I do not have a tools.deps friendly way handy and worked out for running Eastwood from the command line, but if you look at this section of the Eastwood docs on how you can do it from the REPL, without Leiningen involved, you or someone better at tools.deps knowledge than I might be able to figure it out. I'd be happy to add a note like that to the Eastwood README if it isn't too difficult to explain:


Warning: The latest Eastwood 0.2.9 release has a bug in which when you try to use it, it will download (if you don't already have it) and use Eastwood 0.2.8 instead. You may want to simply specify Eastwood 0.2.8 for now, since that is what you will end up using anyway.



clj -Sdeps '{:deps {jonase/eastwood {:mvn/version "0.2.8"}}}' -e "(require '[eastwood.lint :as e])" -e '(e/eastwood {:source-paths ["src"] :test-paths ["test"]})'


You could squirrel most of that away in your ~/.clojure/deps.edn file as an alias...


:eastwood {:extra-deps {jonase/eastwood {:mvn/version "0.2.8"}}
             :main-opts ["-e" "(require,'[eastwood.lint,:as,e])"
                         "-e" "(e/eastwood,{:source-paths,[\"src\"],:test-paths,[\"test\"]})"]}
(note that you need , instead of space!)


I ended up doing this:

:eastwood {:extra-deps {jonase/eastwood {:mvn/version "0.2.8"}}
             :main-opts ["-m" "eastwood.runner"]
             :extra-paths ["test" "tools"]}
And I made a tools directory to contain simple namespaces like that. In this case:
(ns eastwood.runner
  (:require [eastwood.lint :as e]))

(defn -main [& args]
  (e/eastwood {:source-paths ["src"] :test-paths ["test"]}))


Oh, that's nice! :thumbsup::skin-tone-2:


Yeah, I saw that trick on your dot-Clojure and was about to ask! Is that a known bug?


I guess though I can just as easily make a tiny namespace to do this.


@orestis It's to do with how the strings are run through the clojure shell script and into the main opts cache file and then read back. So, yeah, it's a "known feature" 🙂


Right, so it’s not going away any time soon I guess?


I remember some mentions of caching compiled dependencies to speed up startup time - any ideas about that?


More questions - in deps.edn, can you actually override the entire top-level deps entry? Or can you only append?


Rationale: most of my aliases so far have to do with running lint tools, packaging, test runners etc. These namespaces have no need to access my actual app’s classpath. I guess there has bound to be some overhead when the class path is unnecessarily large?


I know that clj will cache the classpath and it’s actually very noticeable.