Fork me on GitHub

Is there any way I can exclude files ?! I have an issue with what might be a broken shaded jar. The issue is because the jar manifest has signatures that are not valid ?! At least that is what I understand. deps.edn:

{:paths ["src" "test" "resources"]
 :deps {org.clojure/clojure {:mvn/version "1.11.1"} {:mvn/version "2.0.0.AM26"}}}
the file
(ns user
  (:import (
the error
; Evaluating file: core.clj
; Execution error (SecurityException) at (
; Invalid signature file digest for Manifest main attributes
; Evaluation of file core.clj failed: class clojure.lang.Compiler$CompilerException
clojure.lang.Compiler/load (
ieugen.ldap-auth-provider.core/eval7557 (NO_SOURCE_FILE:1)
clojure.lang.Compiler/eval (
clojure.core/eval (core.clj:3215)
clojure.core/eval (core.clj:3211)
nrepl.middleware.interruptible-eval/evaluate (interruptible_eval.clj:87)
clojure.core/apply (core.clj:667)
clojure.core/with-bindings* (core.clj:1990)
nrepl.middleware.interruptible-eval/evaluate (interruptible_eval.clj:87)
clojure.main/repl (main.clj:437)
clojure.main/repl (main.clj:458)
clojure.main/repl (main.clj:368)
nrepl.middleware.interruptible-eval/evaluate (interruptible_eval.clj:84)
nrepl.middleware.interruptible-eval/evaluate (interruptible_eval.clj:56)
nrepl.middleware.interruptible-eval/interruptible-eval (interruptible_eval.clj:152)
nrepl.middleware.session/session-exec (session.clj:218)
nrepl.middleware.session/session-exec (session.clj:217)
java.lang.Thread/run (


I managed to get around this by including all the jars instead of the shaded -all jar .


but would be nice to know if there are some knobs in deps


:exclusions tells it to omit a specific (transitive) dependency.


i think the issue is with the jar manifest and the fact that those files exist there with different checksums


I am not familiar with the details


so exclusions might not work in this case


Unfortunately you can't exclude individual files from jars.

👍 1

Hello! I’ve just recently started using as a library (as opposed to via the clj command line tool), and am seeing WARNING: Use of :paths external to the project has been deprecated, please remove: for the first time. We have a monorepo. Each module in the monorepo has its own deps.edn, expressing dependencies on other modules using :local/root. I can imagine motivations for wanting to flag external paths, and I can also imagine scenarios where this is safe. We always want to depend on HEAD: we never want to refer to a specific commit for these dependencies, so using [:git/url :git/sha] and bumping those each time is something we’d rather avoid.


This warning has been in the for a long time (over a year), so I imagine there’s been discussion around this in the past. If people have references at hand to point me to, that’d be appreciated: I don’t mean to rehash all of this if it’s already been addressed.


It looks like is set up to address this.


We have a large monorepo and use :local/root without that warning -- so you must have :paths that point outside the local deps.edn project scope as well? What are you using :paths for that isn't a "local" directory?


I think I’m seeing when using the library directly (e.g., referring to the namespace for monorepo operations). We’re not seeing it when running daily clj commands that rely on the same deps.edn files.


And it’s pointing to all of our local/roots, not some exception.


That warning comes from :paths, not :local/root -- the latter can point outside a project. And if you're not seeing it from the CLI, maybe your CLI is out of date and using a much older t.d.a?


Oh, good call. Thank you, rubber ducky 🙂 (seancorfield rubber ducky is the best rubber ducky)

duckie 1

So, I got to the root of the issue: when supplying a deps-map to via :project. Supplying a path to the source deps.edn file doesn’t have this issue.


So, what I think is happening is that the :local/root in deps is pulling in :paths from those project’s deps.edn files, and those paths are (unsurprisingly) relative to those projects, and external to wherever create-basis thinks the project root is (probably the user.dir, but maybe it knows it doesn’t have one set) calls out these paths as external.


Close, but wrong again. The deps-map I was passing as {:project deps-map} contained absolute paths to paths external to user.dir , which I think is assumed to be project root. Thank you all for your unwilling patience and witnessing me think this through in public.